home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / protocols / gosip-v2.txt < prev    next >
Encoding:
Text File  |  1991-07-10  |  256.9 KB  |  5,699 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.               U. S. Government Open Systems Interconnection Profile (GOSIP)  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.                                      VERSION 2.0
  24.  
  25.                                             October 1990
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.                                            TABLE OF CONTENTS
  34.  
  35.             LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   iv
  36.  
  37.             LIST OF TABLES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    v
  38.  
  39.             FOREWORD  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   vi
  40.  
  41.             PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  vii
  42.  
  43.             GLOSSARY  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
  44.  
  45.             1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    1
  46.                 1.1  BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . .    1
  47.                 1.2  PURPOSE  . . . . . . . . . . . . . . . . . . . . . . . . . . . .    1
  48.                 1.3  EVOLUTION OF THE GOSIP . . . . . . . . . . . . . . . . . . . . .    1
  49.                 1.4  SCOPE  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    2
  50.                 1.5  APPLICABILITY  . . . . . . . . . . . . . . . . . . . . . . . . .    2
  51.                 1.6  GOSIP VERSION 2 FUNCTIONALITY  . . . . . . . . . . . . . . . . .    2
  52.                 1.7  GOSIP Version 1 Errata . . . . . . . . . . . . . . . . . . . . .    3
  53.                 1.8  SOURCES OF PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . .    3
  54.                   1.8.1  Primary Source . . . . . . . . . . . . . . . . . . . . . . .    3
  55.                   1.8.2  Secondary Sources  . . . . . . . . . . . . . . . . . . . . .    3
  56.                   1.8.3  Tertiary Sources . . . . . . . . . . . . . . . . . . . . . .    4
  57.  
  58.             2.  TESTING OF GOSIP-COMPLIANT PRODUCTS . . . . . . . . . . . . . . . . .    5
  59.                 2.1  CONFORMANCE TESTING  . . . . . . . . . . . . . . . . . . . . . .    5
  60.                 2.2  INTEROPERABILITY TESTING . . . . . . . . . . . . . . . . . . . .    5
  61.                 2.3  PERFORMANCE TESTING  . . . . . . . . . . . . . . . . . . . . . .    6
  62.                 2.4  FUNCTIONAL TESTING . . . . . . . . . . . . . . . . . . . . . . .    6
  63.                 2.5  VENDOR ENHANCEMENTS  . . . . . . . . . . . . . . . . . . . . . .    6
  64.  
  65.             3.  DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS  . . . . . . . . . . . . .    7
  66.                 3.1  ARCHITECTURE DESCRIPTION . . . . . . . . . . . . . . . . . . . .    7
  67.                 3.2  PROTOCOL DESCRIPTIONS  . . . . . . . . . . . . . . . . . . . . .   10
  68.  
  69.             4.  PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . . .   12
  70.                 4.1  USE OF THE LAYERED PROTOCOL SPECIFICATIONS . . . . . . . . . . .   12
  71.                   4.1.1  Protocol Selection . . . . . . . . . . . . . . . . . . . . .   12
  72.                   4.1.2  Service Interface Requirements . . . . . . . . . . . . . . .   12
  73.                   4.1.3  Performance Requirements . . . . . . . . . . . . . . . . . .   13
  74.                 4.2  END SYSTEM SPECIFICATION . . . . . . . . . . . . . . . . . . . .   13
  75.                   4.2.1  Physical Layer . . . . . . . . . . . . . . . . . . . . . . .   13
  76.                   4.2.2  Data Link Layer  . . . . . . . . . . . . . . . . . . . . . .   13
  77.                   4.2.3  Network Layer Service  . . . . . . . . . . . . . . . . . . .   14
  78.                         4.2.3.1  Connectionless Mode Network Service  . . . . . . . .   14
  79.                         4.2.3.2  Connection-Oriented Network Service  . . . . . . . .   14
  80.                         4.2.3.3  Network Layer Protocol Identification  . . . . . . .   15
  81.                         4.2.3.4  Special  Provisions For  Integrated Services  Digital
  82.                               Networks  . . . . . . . . . . . . . . . . . . . . . . .   15
  83.                   4.2.4  Transport Layer  . . . . . . . . . . . . . . . . . . . . . .   16
  84.                         4.2.4.1  Connection-Oriented Transport Service  . . . . . . .   16
  85.  
  86.                                                    i
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.                         4.2.4.2  Connectionless Mode Transport Service  . . . . . . .   16
  95.                   4.2.5  Session Layer  . . . . . . . . . . . . . . . . . . . . . . .   16
  96.                   4.2.6  Presentation Layer . . . . . . . . . . . . . . . . . . . . .   17
  97.                   4.2.7  Application Layer  . . . . . . . . . . . . . . . . . . . . .   17
  98.                         4.2.7.1  Association Control Service Elements . . . . . . . .   17
  99.                         4.2.7.2  File Transfer, Access, and Management Protocol (FTAM)   17
  100.                         4.2.7.3  Message Handling Systems . . . . . . . . . . . . . .   17
  101.                         4.2.7.4  Virtual Terminal (VT) Basic Class  . . . . . . . . .   18
  102.                   4.2.8  Exchange Formats . . . . . . . . . . . . . . . . . . . . . .   18
  103.                         4.2.8.1  Office Document Architecture (ODA) . . . . . . . . .   18
  104.                 4.3  INTERMEDIATE SYSTEM SPECIFICATION  . . . . . . . . . . . . . . .   19
  105.  
  106.             5.  ADDRESSING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . .   20
  107.                 5.1  NETWORK LAYER ADDRESSING AND ROUTING . . . . . . . . . . . . . .   20
  108.                   5.1.1   NSAP Address  Administration,  Routing Structures  and  NSAP
  109.                         Address Structure . . . . . . . . . . . . . . . . . . . . . .   20
  110.                   5.1.2  NSAP Address Registration Authorities  . . . . . . . . . . .   22
  111.                         5.1.2.1  Responsibilities Delegated by NIST . . . . . . . . .   22
  112.                   5.1.3  GOSIP Routing Procedures . . . . . . . . . . . . . . . . . .   23
  113.                 5.2  UPPER LAYERS ADDRESSING  . . . . . . . . . . . . . . . . . . . .   23
  114.                   5.2.1  Address Structure  . . . . . . . . . . . . . . . . . . . . .   23
  115.                   5.2.2  Address Assignments  . . . . . . . . . . . . . . . . . . . .   24
  116.                   5.2.3  Address Registration . . . . . . . . . . . . . . . . . . . .   24
  117.                 5.3  IDENTIFYING APPLICATIONS . . . . . . . . . . . . . . . . . . . .   24
  118.                   5.3.1  FTAM and File Transfer User Interface Identification . . . .   24
  119.                   5.3.2  MHS and Message User Interface Identification  . . . . . . .   24
  120.  
  121.             6.  SECURITY OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . . .   26
  122.                 6.1  REASON FOR DISCARD PARAMETERS  . . . . . . . . . . . . . . . . .   26
  123.                 6.2  SECURITY PARAMETER FORMAT  . . . . . . . . . . . . . . . . . . .   27
  124.                   6.2.1  Parameter Code . . . . . . . . . . . . . . . . . . . . . . .   27
  125.                   6.2.2  Parameter Length . . . . . . . . . . . . . . . . . . . . . .   27
  126.                   6.2.3  Parameter Value  . . . . . . . . . . . . . . . . . . . . . .   27
  127.                         6.2.3.1  Security Format Code . . . . . . . . . . . . . . . .   28
  128.                         6.2.3.2  Basic Portion  . . . . . . . . . . . . . . . . . . .   28
  129.                         6.2.3.3  Extended Portion . . . . . . . . . . . . . . . . . .   28
  130.                 6.3  BASIC PORTION OF THE SECURITY OPTION . . . . . . . . . . . . . .   28
  131.                   6.3.1  Basic Type Indicator . . . . . . . . . . . . . . . . . . . .   28
  132.                   6.3.2  Length of Basic Information  . . . . . . . . . . . . . . . .   29
  133.                   6.3.3  Basic Information  . . . . . . . . . . . . . . . . . . . . .   29
  134.                         6.3.3.1  Classification Level . . . . . . . . . . . . . . . .   29
  135.                         6.3.3.2  Protection Authority Flags . . . . . . . . . . . . .   29
  136.                 6.4  EXTENDED PORTION OF THE SECURITY OPTION  . . . . . . . . . . . .   30
  137.                   6.4.1  Extended Type Indicator  . . . . . . . . . . . . . . . . . .   31
  138.                   6.4.2  Length of Extended Information . . . . . . . . . . . . . . .   31
  139.                   6.4.3  Extended Information . . . . . . . . . . . . . . . . . . . .   31
  140.                         6.4.3.1  Additional Security Information Format Code  . . . .   32
  141.                         6.4.3.2  Length of Additional Security Information  . . . . .   32
  142.                         6.4.3.3  Additional Security Information  . . . . . . . . . .   32
  143.                 6.5  USAGE GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . .   33
  144.                   6.5.1  Basic Portion of the Security Option . . . . . . . . . . . .   33
  145.                   6.5.2  Extended Portion of the Security Option  . . . . . . . . . .   33
  146.  
  147.                                                   ii
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.                 6.6  OUT-OF-RANGE PROCEDURE . . . . . . . . . . . . . . . . . . . . .   33
  156.                 6.7  TRUSTED INTERMEDIARY PROCEDURE . . . . . . . . . . . . . . . . .   34
  157.  
  158.             REFERENCES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   35
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.                                                   iii
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.                                               APPENDICES
  217.  
  218.  
  219.             FOREWORD TO THE APPENDICES  . . . . . . . . . . . . . . . . . . . . . . .   41
  220.  
  221.             APPENDIX 1.  SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . .   42
  222.  
  223.             APPENDIX 2.  SYSTEM AND ARCHITECTURE  . . . . . . . . . . . . . . . . . .   46
  224.  
  225.             APPENDIX 3.  UPPER LAYERS   . . . . . . . . . . . . . . . . . . . . . . .   50
  226.  
  227.             APPENDIX 4.  EXCHANGE FORMATS . . . . . . . . . . . . . . . . . . . . . .   56
  228.  
  229.             APPENDIX 5.  LOWER LAYER PROTOCOLS  . . . . . . . . . . . . . . . . . . .   59
  230.  
  231.             APPENDIX 6.  ACRONYMS . . . . . . . . . . . . . . . . . . . . . . . . . .   62
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.                                                   iv
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.                                             LIST OF FIGURES
  278.  
  279.  
  280.             Figure 3.1  GOSIP Version 1 OSI Architecture  . . . . . . . . . . . . . .    8
  281.             Figure 3.2  GOSIP Version 2 OSI Architecture  . . . . . . . . . . . . . .    9
  282.             Figure 5.1.1  NSAP Address Structure  . . . . . . . . . . . . . . . . . .   20
  283.             Figure 5.1.2  The NIST ICD Addressing Domain  . . . . . . . . . . . . . .   21
  284.             Figure 5.1.3  GOSIP NSAP Address Structure  . . . . . . . . . . . . . . .   21
  285.             Figure 5.2.1  Upper Layers Address Structure  . . . . . . . . . . . . . .   24
  286.             Figure A.1  Framework for OSI Security  . . . . . . . . . . . . . . . . .   45
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.                                                    v
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.                                             LIST OF TABLES
  339.  
  340.  
  341.             Table 5.3  Required O/R Name Attributes . . . . . . . . . . . . . . . . .   25
  342.             Table 6.1  Extended Values in the Reason For Discard Parameter  . . . . .   26
  343.             Table 6.2  Security Parameter Format  . . . . . . . . . . . . . . . . . .   27
  344.             Table 6.3  Format - Parameter Value Field . . . . . . . . . . . . . . . .   27
  345.             Table 6.4  Format - Basic Portion . . . . . . . . . . . . . . . . . . . .   28
  346.             Table 6.5  Format - Basic Information Field . . . . . . . . . . . . . . .   29
  347.             Table 6.6  Classification Levels  . . . . . . . . . . . . . . . . . . . .   29
  348.             Table 6.7  Protection Authority Bit Assignments . . . . . . . . . . . . .   30
  349.             Table 6.8  Format - Extended Portion  . . . . . . . . . . . . . . . . . .   31
  350.             Table 6.9  Format - Extended Information Field  . . . . . . . . . . . . .   32
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.                                                   vi
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.                                                FOREWORD 
  400.                  
  401.  
  402.             The U.S. Government  Open Systems Interconnection (OSI)  Advanced Requirements
  403.             Group was established  by the National  Institute of Standards and  Technology
  404.             (NIST) in cooperation  with the Information  Resource Managers of the  Federal
  405.             agencies.  The group's purpose is to coordinate  the acquisition and operation
  406.             of OSI products by the Federal government.  This document specifies  the U. S.
  407.             Government  OSI  profile.    A  profile   is  a  cross-section  of  functional
  408.             applications pertaining to a particular environment.  
  409.  
  410.             It is expected that  the Administrator of the General  Services Administration
  411.             (GSA) will  provide for  the  implementation of  Open Systems  Interconnection
  412.             (OSI) according to this profile.
  413.  
  414.             The National  Institute of  Standards and  Technology (NIST)  will issue  this
  415.             profile as a Federal Information Processing  Standard (FIPS).  This is Version
  416.             2  of the Government  Open Systems  Interconnection Profile.   It  contains an
  417.             updated  specification  of the  OSI  protocols  that  meet  government  needs.
  418.             Products based  on these protocols  are or soon  will be available  from major
  419.             vendors.
  420.  
  421.             Organizations contributing to the development of this profile are given below.
  422.  
  423.             Department of Agriculture
  424.             Department of Commerce
  425.             Department of Defense
  426.             Department of Energy
  427.             Department of Education
  428.             Department of Health and Human Services
  429.             Department of Housing and Urban Development 
  430.             Department of the Interior
  431.             Department of Justice
  432.             Department of Labor
  433.             Department of Transportation 
  434.             Department of the Treasury
  435.             Environmental Protection Agency
  436.             General Services Administration
  437.             Library of Congress
  438.             National Aeronautics and Space Administration
  439.             National Communications System
  440.             National Science Foundation
  441.             Office of Management and Budget
  442.             Veterans Administration
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.                                                   vii
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.                                                 PREFACE
  461.  
  462.  
  463.             This is a  Federal Government  procurement profile for  open systems  computer
  464.             network products.  Section  1 contains introductory material, the  purpose and
  465.             scope of the profile, and the sources of the protocol specifications contained
  466.             in  the  profile.   Section  2  contains  general  statements on  conformance,
  467.             interoperation and  performance of network  systems covered  by this  profile.
  468.             Section 3 contains a  brief description of the OSI  architecture and protocols
  469.             that apply to this profile. The network  protocols are specified in section 4,
  470.             the principal part of this profile.  Accompanying each protocol implementation
  471.             reference  is a statement  of conformance identifying  the required functional
  472.             units  of that  protocol.   section  5,  Addressing Requirements,  is also  an
  473.             integral and mandatory  part of this profile.   Technical Support Personnel to
  474.             Acquisition  Authorities  must be  familiar  with  the terminology  and  ideas
  475.             expressed in sections 4 and 5.  
  476.  
  477.             Section  6  defines  security options  that,  if  needed,  must be  explicitly
  478.             requested in Requests For Proposals.
  479.  
  480.             This  profile  will  change  with  improvements  in technology  and  with  the
  481.             evolution of network protocol standards.  Appendices specify future work items
  482.             needed to enrich the profile, and thus, improve its utility to the agencies.
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.                                                  viii
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.                                                GLOSSARY
  522.  
  523.  
  524.             The terms defined below are used frequently throughout this profile.  They are
  525.             defined here to aid the lay reader.  Other terms appearing in sections 4 and 5
  526.             are defined  in Federal  Standard 1037A and  ISO 7498  and must  be thoroughly
  527.             understood by the Technical Support Personnel to Acquisition Authorities.
  528.  
  529.             Protocol
  530.  
  531.             In  the  Open  Systems  Interconnection  reference  model,  the  communication
  532.             functions  are  partitioned into  seven  layers.   Each layer,  N,  provides a
  533.             service to the layer above, N+1, by carrying on a conversation with layer N on
  534.             another processor.  The rules and conventions of that N-layer conversation are
  535.             called a protocol.
  536.  
  537.             End System
  538.  
  539.             An end system  (ES) contains the  application processes that are  the ultimate
  540.             sources and destinations  of user oriented message flows.  The functions of an
  541.             end system can be distributed among more than one processor/computer.
  542.  
  543.             Intermediate System
  544.  
  545.             An  intermediate  system (IS)  interconnects  two  or more  subnetworks.   For
  546.             example, it might connect  a local area network with a wide  area network.  It
  547.             performs  routing and  relaying of  traffic.   A processor  can  implement the
  548.             functions of both an end system and an intermediate system.
  549.  
  550.             A  system  implementing  all seven  layers  of  protocol  may provide  service
  551.             directly to users  (acting as an end  system), and it may  connect subnetworks
  552.             (acting  as an  intermediate system).   When it  performs the functions  of an
  553.             intermediate system, only the lower three layers of protocol are exercised.
  554.  
  555.             Open System
  556.  
  557.             An open system is a system capable of communicating with other open systems by
  558.             virtue of implementing  common international standard protocols.   End systems
  559.             and intermediate systems are open systems.  However, an open system may not be
  560.             accessible by  all other  open systems.   This  isolation may  be provided  by
  561.             physical  separation or  by  technical capabilities  based  upon computer  and
  562.             communications security.
  563.  
  564.             Federal Government Terminology  
  565.  
  566.             The following  definitions are informal  and generic and are  provided for the
  567.             benefit  of  private sector  organizations that  review  the profile.   Agency
  568.             regulations and any contract should be referred to for precise terms and their
  569.             usage.  Also, other terms  may be used in lieu of these  in agency regulations
  570.             and in specific contracts.
  571.  
  572.             Acquisition Authority  
  573.  
  574.                                                   ix
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.             An  Acquisition  Authority, commonly  known as  a  contracting officer,  is an
  584.             individual  who,  under  Federal  law  and  acquisition regulations,  has  the
  585.             authority to enter into, administer, and/or terminate a government contract.
  586.  
  587.             Federal Acquisition Regulation (FAR)   
  588.  
  589.             The FAR is  applicable to Executive  departments and agencies  of the  Federal
  590.             Government  in  the  area of  acquisition,  leasing,  and  rental of  personal
  591.             property  and  services.   Many  departments and  agencies  have supplementary
  592.             regulations that apply to their acquisitions.
  593.  
  594.             Federal Information Resources Management Regulation (FIRMR)
  595.  
  596.             The FIRMR is  applicable to federal departments  and agencies in the  areas of
  597.             management, acquisition and use of  information resources, including automatic
  598.             data processing and telecommunications equipment and services.
  599.              
  600.             Requests For Proposals (RFP) 
  601.  
  602.             Requests For Proposals  are documents issued by the government to request bids
  603.             for products or services.
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.                                                    x
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.                                            1. INTRODUCTION  
  644.  
  645.  
  646.             1.1  BACKGROUND
  647.  
  648.             Both the government and the private sector recognize the need to develop a set
  649.             of common data communication protocols based on the International Organization
  650.             for  Standardization's seven-layer  Open Systems  Interconnection  (OSI) Basic
  651.             Reference Model [ISO 1].  In the past, vendor-specific implementations of data
  652.             communication protocols led to isolated domains of information, very difficult
  653.             and expensive to bridge.  Recent advances in communication technology based on
  654.             the OSI model offer  alternatives to vendor-specific network solutions.   Most
  655.             significantly,  advances in  open  systems  allow  the interoperation  of  end
  656.             systems of different manufacture, when required.  
  657.  
  658.             This  Government  Open Systems  Interconnection  Profile (GOSIP)  is  based on
  659.             agreements  reached at  the  National Institute  of  Standards and  Technology
  660.             (NIST) Workshop for  Implementors of Open  Systems Interconnection.  Each  new
  661.             version of  GOSIP will reference the latest  appropriate version of the Stable
  662.             Implementation Agreements for Open Systems Interconnection Protocols [NIST 1],
  663.             hereafter referred to  as the  Workshop Agreements.   The Workshop  Agreements
  664.             record  stable   implementation  agreements   of  OSI   protocols  among   the
  665.             organizations participating in the NIST Workshop for Implementors of OSI.  
  666.  
  667.             A new version of the  Workshop Agreements is created each year at the December
  668.             OSI Implementors'  Workshop meeting.   It is the  intent of the  NIST Workshop
  669.             that new versions  of the  Workshop Agreements will  be backwardly  compatible
  670.             with previous  versions.    New editions of the  same version of  the Workshop
  671.             Agreements  are published at  regular intervals  during the  year.   These new
  672.             editions contain errata and clarifications to the original agreements that are
  673.             approved by the Workshop  plenary.  The latest editions  are being distributed
  674.             to all workshop  attendees and  are available through  the National  Technical
  675.             Information Service (NTIS).  See NIST Reference 1 for ordering information.  
  676.  
  677.             GOSIP is  also consistent with  and complementary to  industry's Manufacturing
  678.             Automation Protocol (MAP)  [MISC 1] and  Technical and Office Protocols  (TOP)
  679.             [MISC 2] specifications.  GOSIP  addresses the need of the  Federal Government
  680.             to  move immediately  to  multi-vendor  interconnectivity without  sacrificing
  681.             essential functionality  already implemented in  critical networking  systems.
  682.             All capabilities  described herein  exist as  standard products  or are  close
  683.             enough to market that they can be proposed by vendors.
  684.  
  685.             1.2  PURPOSE
  686.  
  687.             This profile is the standard reference for  all federal government agencies to
  688.             use when acquiring  and operating  ADP systems or  services and  communication
  689.             systems or services  intended to conform  to ISO Open Systems  Interconnection
  690.             protocols which provide interoperability in a heterogeneous environment.  
  691.             1.3  EVOLUTION OF THE GOSIP
  692.  
  693.             The  GOSIP  FIPS  will  be updated  by  issuing  new  versions  at appropriate
  694.             intervals to  reflect the  progress  being made  by vendors  in providing  OSI
  695.  
  696.                                                    1
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.             products with new services useful to Federal agencies.  A new version of GOSIP
  705.             will supersede  the previous version  of the document because  it will include
  706.             all of the protocols  in the previous  version plus additional new  protocols.
  707.             Procurement of the new  protocols is mandated in Federal  procurement requests
  708.             initiated  eighteen  months  after  the  version  of  GOSIP  containing  those
  709.             protocols is promulgated as  a FIPS.  Every new version of  GOSIP will specify
  710.             the  architecture and protocols  that were  included in  each of  the previous
  711.             versions  so  that  Federal  agencies  can  easily  determine  the  applicable
  712.             compliance date for each protocol.
  713.  
  714.             It is a goal that a new version of GOSIP will be upwardly compatible  with the
  715.             previous versions.  However, changes may be required to correct errors  and to
  716.             align with activity in the international  standards organizations.  Any errata
  717.             required to  a previous version of  GOSIP will be identified in  the new GOSIP
  718.             version.    Unless otherwise  stated,  the  mandatory compliance  date  of the
  719.             previous version of GOSIP also 
  720.  
  721.             applies to the errata. These errata will not be included without ensuring that
  722.             they  have the strong support of the vendors who are providing OSI products so
  723.             that  users   can  be   confident  that   these  changes   will  not   inhibit
  724.             interoperability.  See section 1.7 for the GOSIP Version 1 errata.
  725.  
  726.             1.4  SCOPE
  727.  
  728.             In an increasingly complex world, the need to exchange information has  become
  729.             an ever more important factor  in conducting business.  Federal  agencies need
  730.             to share information not only with other Federal agencies, but with  state and
  731.             local  governments  and commercial  organizations  as well.    Until recently,
  732.             computer  networking  technology  has   not  kept  pace  with  this   need  to
  733.             communicate.    Even now,  many Federal  agencies  have "islands"  of computer
  734.             systems built  by  different  vendors, or  by  the same  vendor,  that  cannot
  735.             interoperate.
  736.  
  737.             The GOSIP, in addition to being a Federal mandate, is an alert that the vendor
  738.             community  has developed  a  nonproprietary solution  for this  requirement to
  739.             exchange information.   The solution is the OSI  protocols upon which GOSIP is
  740.             based.    Version 1  of GOSIP  (FIPS  146) provided  electronic mail  and file
  741.             transfer services using the  OSI standards for Message Handling  Systems (MHS)
  742.             and File Transfer, Access, and Management (FTAM).  Version 1 of GOSIP provided
  743.             interoperability among users on X.25, 802.3, 802.4, and 802.5 subnetworks.  In
  744.             addition,  Version 1  of GOSIP created  a foundation  upon which to  build new
  745.             protocols providing new services useful to Federal agencies.
  746.  
  747.             Version 2  of GOSIP  (FIPS 146-1)  uses that  foundation to  provide a  remote
  748.             terminal access capability using  the Virtual Terminal (VT) standard.   At the
  749.             network  layer,  Version 2  of GOSIP  extends  interoperabity to  include ISDN
  750.             subnetworks.   Future  versions of GOSIP  will add  new user services  such as
  751.             Directory  Services, Transaction  Processing, Electronic Data  Interchange and
  752.             Remote  Data Base Access as well as  allow interoperability among users served
  753.             by other network technologies.
  754.  
  755.             GOSIP  does  not  mandate  that  government agencies  abandon  their  favorite
  756.  
  757.                                                    2
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.             computer networking products.   GOSIP does  mandate that government  agencies,
  766.             when  acquiring  computer networking  products,  purchase OSI  capabilities in
  767.             addition  to  any other  requirements,  so that  multi-vendor interoperability
  768.             becomes a  built-in feature of the government computing environment, a fact of
  769.             life in conducting government business.
  770.  
  771.             The OSI protocols have the potential to  change the way the Federal Government
  772.             does  business.   It  is  essential that  Federal  agencies  make a  strategic
  773.             investment in OSI  beginning now, so that they will be well positioned to take
  774.             advantage of the  new services provided  by the OSI  protocols as they  become
  775.             available.  Planning the integration of  OSI may require considerable time and
  776.             effort, but this work will be more than offset by the benefits provided by the
  777.             new technology.
  778.              
  779.             1.5  APPLICABILITY 
  780.  
  781.             GOSIP  specifies a  set  of  OSI protocols  for  computer  networking that  is
  782.             intended for acquisition and use by  government agencies.  It must be  used by
  783.             all Federal  government agencies  when acquiring  products and services  which
  784.             provide  equivalent functionality  to  the OSI  protocols  referenced in  this
  785.             document.  For a more detailed statement of applicability, see FIPS 146. 
  786.  
  787.             1.6  GOSIP VERSION 2 FUNCTIONALITY
  788.  
  789.             Version  2  of GOSIP  contains  the  following functionality  not  included in
  790.             Version 1.
  791.  
  792.                 1.  The Virtual Terminal Service (TELNET and Forms profiles);
  793.                 2.  The Office Document Architecture (ODA); 
  794.                 3.  The Integrated Services Digital Network (ISDN);
  795.                 4.   The End  System-Intermediate  System protocol  (ES-IS),  and as  user
  796.             options;
  797.                 5.  The Connectionless Transport Service (CLTS); and,
  798.                 6.  The Connection-Oriented Network Service (CONS).
  799.  
  800.             The compliance information for GOSIP Version 2 functions is stated in the FIPS
  801.             announcement.  Since  the Connectionless Transport Service and the Connection-
  802.             Oriented  Network Service are provided as optional  user services, there is no
  803.             mandatory compliance specified.  All GOSIP protocols not included in the above
  804.             list are  bound by the  GOSIP Version  1 compliance date  which is  August 15,
  805.             1990.  Figure 3.1 illustrates the GOSIP Version 1 architecture  and protocols.
  806.             Figure 3.2 illustrates the GOSIP Version 2 architecture and protocols.
  807.  
  808.             1.7  GOSIP Version 1 Errata
  809.  
  810.                 1.    Since Version  1 of  the  Stable Implementation  Agreements  for OSI
  811.             Protocols was published, errata have been added to those agreements, primarily
  812.             by  the FTAM and Upper  Layer Special Interest  Groups (SIGs) of  the NIST OSI
  813.             Implementors' Workshop to correct  problems in the original agreements  and to
  814.             align with agreements  being developed  internationally.  Version  1 of  GOSIP
  815.             will  now  reference  the  relevant  sections  of  Version  3  of  the  Stable
  816.             Implementation Agreements.   Text  for these  sections is  available from  the
  817.  
  818.                                                    3
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.             Government Printing Office and NTIS.
  827.  
  828.                 2.   Version  1 of GOSIP (section  5.3.2) required  that private messaging
  829.             systems within the  government be capable  of routing on administration  name,
  830.             private domain name, organization  name, organization unit and personal  name.
  831.             The requirement that private messaging systems  be capable of routing based on
  832.             personal name has  been deleted.  This  change expands the range  of messaging
  833.             systems that are GOSIP compliant.
  834.  
  835.                 3.   GOSIP Version 1 implementations should use the Network Service Access
  836.             Point (NSAP)  Address structure  in Figure  5.1.3 of  GOSIP Version  2.   This
  837.             change was made to align with the  routing standards currently being developed
  838.             by the ISO.
  839.  
  840.                 4.    Version 1  of  GOSIP  (section 4.2.3)  required  that processing  of
  841.             Protocol  Data Units by the Connectionless Network  Layer Protocol be in order
  842.             of priority.  This requirement has been deleted.
  843.  
  844.                 5.  Version 1 of GOSIP  describes a general architecture for OSI security,
  845.             defines a set of optional security  services that may be supported within  the
  846.             OSI  model, and outlines a number of mechanisms  that can be used in providing
  847.             the service.  Users  should now refer to the updated  Security Options section
  848.             in Version 2 of GOSIP.   It should be noted that, even in  Version 2 of GOSIP,
  849.             the security  section is optional  and is considered a  placeholder for future
  850.             security specifications. 
  851.  
  852.             1.8  SOURCES OF PROTOCOL SPECIFICATIONS
  853.  
  854.             1.8.1  Primary Source
  855.  
  856.             The  primary  source  of  protocol  specifications  in  GOSIP  is  the  Stable
  857.             Implementation Agreements for Open Systems Interconnection Protocols [NIST 1].
  858.              This source  document was created and is maintained  by the NIST Workshop for
  859.             Implementors  of  Open Systems  Interconnection.   It  provides implementation
  860.             specifications that are derived from service  and protocol standards issued by
  861.             the  International Organization  for Standardization  (ISO),  the Consultative
  862.             Committee  for  International  Telegraphy  and   Telephony  (CCITT),  and  the
  863.             Institute of Electrical and Electronics Engineers, Inc. (IEEE).
  864.  
  865.             By primary  source, it is  meant that  where GOSIP uses  a given  protocol, it
  866.             cites that  protocol by  reference as  specified in  the above-named  Workshop
  867.             Agreements.  The primary source is used in all instances where the protocol of
  868.             interest has been  specified in the  Workshop Agreements.   Section 4 of  this
  869.             profile gives conformance  statements for each  protocol that, in some  cases,
  870.             are  augmented  from  the  minimal  conformance  statements  in  the  Workshop
  871.             Agreements  in  order to  provide  the functionality  required  for government
  872.             computer networking.
  873.  
  874.             1.8.2  Secondary Sources
  875.  
  876.             GOSIP  must be complete  in that open  systems procured in  accordance with it
  877.             must interoperate and  must provide  service generally  useful for  government
  878.  
  879.                                                    4
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.             computer networking applications.  The Workshop Agreements continue to evolve,
  888.             but they are  still incomplete.  (The  appendices of GOSIP cite  needed work.)
  889.             Thus, where the  Workshop Agreements  do not provide  completeness, GOSIP  may
  890.             augment protocol and service specifications from the following sources, listed
  891.             in precedence order.
  892.  
  893.                 o International Standards and Recommendations
  894.                 o Draft International Standards
  895.                  
  896.             Since this  profile is  one of  open systems,  the  secondary sources  include
  897.             specifications that  are international  standards or  are advancing  to become
  898.             international standards.   They are included in  GOSIP, where needed, to  help
  899.             satisfy the criterion of completeness, and thus, utility.  Note that secondary
  900.             sources  exclude  protocols, however  mature,  that  are  not a  part  of  the
  901.             international standards process.
  902.  
  903.             1.8.3  Tertiary Sources
  904.  
  905.             Even the secondary sources  named above may not provide a  complete and useful
  906.             networking system today.   It may be  necessary for GOSIP to  augment protocol
  907.             and  service specifications from  the following sources,  listed in precedence
  908.             order.
  909.  
  910.                 o ANSI Standards
  911.                 o       Draft Proposed International Standards
  912.                 o       Federal Information Processing Standards
  913.                 o       Military Standards
  914.  
  915.             For  example, security protocols  might be incorporated from  a FIPS issued by
  916.             NIST.  The use  of protocols from other than the primary and secondary sources
  917.             is  undesirable.  It is expressly intended that these omissions from standards
  918.             work be brought to the attention of the international standards bodies so that
  919.             acceptable international  standards may be  developed as rapidly  as possible.
  920.             The  GOSIP  Advanced  Requirements  Group  will replace  all  tertiary  source
  921.             protocols in  GOSIP with suitable  primary and  secondary source  substitutes,
  922.             when available.
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.                                                    5
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.                                 2.  TESTING OF GOSIP-COMPLIANT PRODUCTS
  949.  
  950.  
  951.             Conformance testing verifies that an implementation  acts in accordance with a
  952.             particular specification, such as GOSIP.   Interoperability testing duplicates
  953.             the  "real-life"  environment  in  which   an  implementation  will  be  used.
  954.             Performance  testing  measures   whether  an   implementation  satisfies   the
  955.             performance criteria of the user.  Functional testing determines the extent to
  956.             which an implementation meets user functional requirements.  
  957.  
  958.             NIST  issued  GOSIP Version  1.0  testing  guidance in  GOSIP  Conformance and
  959.             Interoperation Testing and Registration [NIST 8].   Consult that reference for
  960.             detailed   procedures,   instructions  for   GOSIP   product  suppliers,   and
  961.             recommendations  for Acquisition  Authorities.   A  future  revision to  GOSIP
  962.             Conformance and Interoperation  Testing and Registration will  add procedures,
  963.             instructions,  and  recommendations for  the new  protocols included  in GOSIP
  964.             Version 2.0.  Until such revision occurs, Federal agency personnel should use,
  965.             for testing GOSIP Version  2.0 additions, the interim guidance  supplied below
  966.             in sections 2.1 and 2.2.
  967.  
  968.             NIST issued Message Handling Systems Evaluation  Guidelines [NIST 9] to assist
  969.             Federal agency  personnel to  evaluate the  degree to  which specific  Message
  970.             Handling  Systems  products  meet  the  specific  performance  and  functional
  971.             requirements of an agency  procurement.  Further guidelines are  planned; File
  972.             Transfer, Access and Management will be the  next.  If a guideline is not  yet
  973.             available for an application of interest,  Federal agency personnel should use
  974.             the interim guidance supplied in sections 2.3, 2.4, and 2.5.
  975.  
  976.             2.1  CONFORMANCE TESTING
  977.  
  978.             Conformance is shown  by the vendor  having passed conformance tests  adequate
  979.             for the  purpose of  exercising the functional  units specified in  section 4.
  980.             Conformance to  the  GOSIP will  only  apply to  the  profile defined  by  the
  981.             Acquisition  Authority.    For the  purposes  of  testing  conformance to  the
  982.             protocols required  by  GOSIP  Version  2.0, the  Acquisition  Authority  will
  983.             provide documentation which identifies specific testing requirements. 
  984.  
  985.             Conformance tests and  test systems are  currently being developed by  several
  986.             testing organizations.   When  these test  systems for  GOSIP Version  2.0 are
  987.             completed, NIST will specify the tests, test systems and testing organizations
  988.             that are accredited to perform conformance testing of GOSIP protocols.
  989.  
  990.             For  the  interim,  the  Acquisition  Authority  shall  require  that  vendors
  991.             substantiate any claim of GOSIP conformance.
  992.  
  993.             The  Acquisition  Authority shall  also  be responsible  for  determining that
  994.             acceptable test results are available as a prerequisite to awarding of a final
  995.             procurement contract.
  996.  
  997.             2.2  INTEROPERABILITY TESTING
  998.  
  999.             The Acquisition Authority should  specify a detailed set of  requirements that
  1000.  
  1001.                                                    6
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.             will  serve  to test  interoperability of  GOSIP Version  2.0 protocols.   The
  1010.             Acquisition Authority must specify the following for this testing:
  1011.  
  1012.                 - the  products  to  be  used   for  the  interoperability  testing,
  1013.                   including hardware and software versions and components,
  1014.  
  1015.                 - a detailed description of planned test scenarios to be run between
  1016.                   implementations  in the  interoperability  testing, including  the
  1017.                   results expected, and
  1018.  
  1019.                 - criteria for passing or failing the testing.
  1020.  
  1021.             NIST  will  recommend  vehicles  particularly  suitable  for  interoperability
  1022.             testing.
  1023.  
  1024.  
  1025.             2.3  PERFORMANCE TESTING
  1026.  
  1027.             The  principal  thrust  of  OSI  is  to provide  interworking  of  distributed
  1028.             applications using heterogeneous,  multi-vendor systems.  GOSIP  does not cite
  1029.             performance criteria.    Note that  protocol  definitions include  quality  of
  1030.             service  parameters and  other tunable functions.   The  Acquisition Authority
  1031.             must determine and specify those performance related features that are desired
  1032.             to be under user or application process control and those desired to be  under
  1033.             system operator control.   The Acquisition Authority may  also wish to specify
  1034.             benchmarking criteria as evidence of satisfying performance requirements.
  1035.  
  1036.             2.4  FUNCTIONAL TESTING
  1037.  
  1038.             The GOSIP specification mandates for each protocol a minimum set  of functions
  1039.             to  meet  general  government  requirements.    In  many  instances additional
  1040.             functions  might be  supported  within  the  Workshop  Agreements  and/or  the
  1041.             protocol standard.  The Acquisition Authority  must determine and specify such
  1042.             additional functions that are required within an acquisition.  The Acquisition
  1043.             Authority is  responsible for determining  that the  vendor products  proposed
  1044.             meet any and all functional requirements.
  1045.  
  1046.             2.5  VENDOR ENHANCEMENTS
  1047.               
  1048.             It is expected that most vendors will update their products, for example, from
  1049.             a Draft International Standard  version to an International Standard  version,
  1050.             as implementation  specifications are  completed in  the Workshop  Agreements.
  1051.             Also, some vendors may provide additional functionality.  Implementations that
  1052.             go  beyond the  functional  units  stated in  section  4  must be  implemented
  1053.             according to the  Workshop Agreements and must interwork  with implementations
  1054.             that strictly comply with section 4.  Requests For  Proposals should encourage
  1055.             vendor enhancements where required to meet user needs.
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.                                                    7
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.  
  1069.  
  1070.                             3.  DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS
  1071.  
  1072.  
  1073.             This section  briefly describes the GOSIP  architecture and protocols.   For a
  1074.             more   thorough   understanding,   consult   the   Government   Open   Systems
  1075.             Interconnection  User's  Guide [NIST  7] and  other  references cited  in this
  1076.             profile. 
  1077.  
  1078.             3.1  ARCHITECTURE DESCRIPTION
  1079.  
  1080.             Figure 3.1 illustrates the GOSIP Version 1 architecture and protocols.  Figure
  1081.             3.2 shows how  new protocols providing new  services have been added  to GOSIP
  1082.             Version 2 while maintaining compatibility with GOSIP Version 1.
  1083.  
  1084.             Achieving  OSI within  the government is  best accomplished by  using a single
  1085.             method (one protocol  profile at each OSI  layer) to perform the  functions of
  1086.             routing and reliable data transfer.   Fig. 3.2 shows that these functions  are
  1087.             provided by the transport class 4, and connectionless network layer protocols.
  1088.             Mandatory  use  of  a  single  transport  protocol  class  (class  4)   and  a
  1089.             connectionless  network  layer  protocol  (CLNP)  assures  interoperable  data
  1090.             transfer  between government computer  systems for  a variety  of applications
  1091.             across  a  variety of  subnetwork technologies.    Optional use  of additional
  1092.             transport and network layer protocols is  not precluded by GOSIP; in fact,  as
  1093.             shown  in  Figure  3.2, GOSIP  now  includes  specifications  for an  optional
  1094.             connectionless transport  service and an  optional connection-oriented network
  1095.             service.  The specifications give sufficient detail for achieving interworking
  1096.             among government computer systems implementing these options. 
  1097.  
  1098.             It is  useful  to enable  user  selection from  among  a set  of  lower  layer
  1099.             subnetwork technologies for local  and wide area networking.   These different
  1100.             technologies exhibit physical,  performance, and cost differences  that render
  1101.             one technology  more appropriate  than others for  particular uses.   Fig. 3.2
  1102.             illustrates six subnetwork  technologies specified  by GOSIP.   These are  the
  1103.             packet data network (X.25),  the point to point (Pt-Pt) LAP  B Subnetwork, the
  1104.             Integrated Services Digital  Network (ISDN), the  Token Bus (ISO 8802/4),  the
  1105.             Token Ring (ISO  8802/5) and the Carrier Sense  Multiple Access with Collision
  1106.             Detection  (ISO  8802/3).   When a  point  to point  or local  area subnetwork
  1107.             technology  is selected, the CLNP end system  to intermediate system (CLNP ES-
  1108.             IS) routing protocol [ISO 44] is also required.  Other lower  layer subnetwork
  1109.             technologies may be  used, but the  Acquisition Authority must provide  proper
  1110.             specification  to  ensure procurement  of  an  effective product,  that  is, a
  1111.             product able to  support operation  of transport class  4, the  connectionless
  1112.             network protocol, and the GOSIP upper layer protocols.
  1113.  
  1114.             Interconnection of multiple  wide-area networks  to form the  appearance of  a
  1115.             single logical  wide-area  network  may be  accomplished  by  any  technically
  1116.             appropriate means such as X.75 gateways.  Interconnection of remote local area
  1117.             networks  to   form  the  appearance  of  a  single  logical  network  may  be
  1118.             accomplished by any technically  appropriate means, such as  MAC bridges.   In
  1119.             all other instances, the GOSIP mandates subnetwork interconnection by means of
  1120.             the CLNP and the network access methods appropriate  for the specific networks
  1121.             being interconnected.  
  1122.  
  1123.                                                    8
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.             At the application  layer, many protocols are expected to be included in GOSIP
  1133.             over  time,  each  applying to  different  uses.   In  Fig.  3.2,  the current
  1134.             application protocols are File Transfer, Access and Management (FTAM) based on
  1135.             the ISO International Standard  [ISO 16-19], the Basic Class  Virtual Terminal
  1136.             Protocol based  on the  ISO International  Standard [ISO  32-35], and  Message
  1137.             Handling Systems based  on the  1984 CCITT Recommendations  [CCITT 2-9].  Each
  1138.             application  may  require  a  different  selected  set of  services  from  the
  1139.             application  control service elements and the presentation and session control
  1140.             layers.  Thus, layers 5, 6, and 7 may  be thought of as an integral package of
  1141.             GOSIP upper layer protocols for each specific application.
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.                                                    9
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.  
  1193.             Figure 3.1  GOSIP Version 1 OSI Architecture
  1194.  
  1195.  
  1196.  
  1197.  
  1198.  
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204.  
  1205.  
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.                                                   10
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.             Figure 3.2  GOSIP Version 2 OSI Architecture
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.                                                   11
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.             The Office Document Architecture (ODA) standard based on the ISO International
  1315.             Standards [ISO 36-42, CCITT 17-24] is also included in GOSIP.  Although ODA is
  1316.             not an  OSI protocol,  it is included  in GOSIP  because it  provides services
  1317.             required by Federal agencies,  and the information specified by  the standards
  1318.             can be transported by the OSI FTAM and MHS Application layer protocols.
  1319.  
  1320.             A  goal  of  this profile  is  to  permit an  Acquisition  Authority  to issue
  1321.             unambiguous  procurement  requests  for standard  applications  operating over
  1322.             networks using standard  protocols.  The Acquisition Authority  determines the
  1323.             required applications  and the  required networks  and the  GOSIP defines  the
  1324.             required  protocols.   For  example, if  an  Acquisition Authority  requires a
  1325.             general purpose File Transfer  Access and Management application on  a CSMA/CD
  1326.             subnetwork, the GOSIP defines that layer 7 FTAM is required along with certain
  1327.             services  from  the application  control  service elements,  presentation, and
  1328.             session protocols.   To perform the data transfer function, GOSIP mandates the
  1329.             Class 4 transport protocol and the  connectionless network layer protocol, and
  1330.             defines  a subset of  the ISO 8802/2  link layer,  and the ISO  8802/3 CSMA/CD
  1331.             protocol.
  1332.  
  1333.             3.2  PROTOCOL DESCRIPTIONS
  1334.  
  1335.             Following are brief narratives  of the general services provided  by protocols
  1336.             in each layer of the GOSIP architecture to the layer above.  
  1337.  
  1338.             The Application layer (layer 7) allows for protocols and services required  by
  1339.             particular  user-designed   application  processes.     Functions   satisfying
  1340.             particular user requirements are contained in  this layer.  Representation and
  1341.             transfer of information  necessary to communicate between applications are the
  1342.             responsibility of the lower layers.  See References [NIST 1; ISO 1, 16-19, 22-
  1343.             25, 32-35; CCITT 2-9, 14].
  1344.  
  1345.             The Presentation layer (layer 6) specifies  or, optionally, negotiates the way
  1346.             information  is  represented  for  exchange  by  application  entities.    The
  1347.             presentation layer provides the representation of: 1) data transferred between
  1348.             application entities, 2) the data structure that the application entities use,
  1349.             and  3)  operations on  the  data's  structure.   The  presentation  layer  is
  1350.             concerned only with the syntax of the transferred data.  The data's meaning is
  1351.             known only to  the application entities, and  not to the presentation  layer. 
  1352.             See References [NIST 1; ISO 1,20,21,24,25].  
  1353.  
  1354.             The  Session layer  (layer  5)  allows  cooperating  application  entities  to
  1355.             organize  and  synchronize  conversation and  to  manage  data  exchange.   To
  1356.             transfer the data,  session connections use  transport connections.  During  a
  1357.             session,  session  services  are  used  by  application  entities to  regulate
  1358.             dialogue by ensuring  an orderly message  exchange on the session  connection.
  1359.             See References [NIST 1; ISO 1,14,15; CCITT 12,13].
  1360.  
  1361.             The Transport layer  (layer 4) connection-oriented service  provides reliable,
  1362.             transparent  transfer of  data  between  cooperating  session entities.    The
  1363.             transport layer  entities optimize the  available network services  to provide
  1364.             the performance required by each session  entity.  Optimization is constrained
  1365.             by the overall demands  of concurrent session entities and  by the quality and
  1366.  
  1367.                                                   12
  1368.  
  1369.  
  1370.  
  1371.  
  1372.  
  1373.  
  1374.  
  1375.             capacity of the  network services available  to the transport layer  entities.
  1376.             In the connection-oriented transport service,  transport connections have end-
  1377.             to-end significance,  where  the ends  are  defined as  corresponding  session
  1378.             entities  in   communicating  end  systems.     Connection-oriented  transport
  1379.             protocols regulate flow, detect  and correct errors, and multiplex data, on an
  1380.             end-to-end  basis.  See  References [NIST 1;  ISO 1,12,13; CCITT  10,11].  The
  1381.             transport layer also supports  a simple connectionless transport  service [ISO
  1382.             46-47]. 
  1383.  
  1384.             The Network layer  (layer 3) provides message routing and relaying between end
  1385.             systems on the same network or  on interconnected networks, independent of the
  1386.             transport  protocol  used.   The  network  layer may  also  provide hop-by-hop
  1387.             network  service  enhancements, flow  control,  and load  leveling.   Services
  1388.             provided  by  the network  layer are  independent  of the  distance separating
  1389.             interconnected networks.  See References  [NIST 1,3; ISO 1-8,11; CCITT  1; NCS
  1390.             1].
  1391.  
  1392.             The Data  link  layer (layer  2) provides  communication between  two or  more
  1393.             (multicast service)  adjacent systems.   The  data link  layer performs  frame
  1394.             formatting,  error  checking,  addressing, and  other  functions  necessary to
  1395.             ensure accurate data  transmission between  adjacent systems.   Note that  the
  1396.             data  link  layer can  operate in  conjunction  with several  different access
  1397.             methods in the physical layer.   See Figure 3.2 for examples.   See References
  1398.             [NIST 1-3,5; ISO 1,26,28; CCITT 1].
  1399.  
  1400.             The Physical layer (layer  1) provides a physical connection  for transmission
  1401.             of  data  between  data  link  entities.    Physical  layer  entities  perform
  1402.             electrical encoding  and decoding of the  data for transmission over  a medium
  1403.             and regulate access to the physical network.  See References [NIST 1-3; ISO 1;
  1404.             ISO 29-31; IEEE 1].
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.  
  1427.  
  1428.                                                   13
  1429.  
  1430.  
  1431.  
  1432.  
  1433.  
  1434.  
  1435.  
  1436.                                       4.  PROTOCOL SPECIFICATIONS
  1437.  
  1438.              
  1439.             4.1  USE OF THE LAYERED PROTOCOL SPECIFICATIONS
  1440.  
  1441.             The individual protocol and interface specifications  in this section shall be
  1442.             used directly in  Requests For  Proposals.   However, Acquisition  Authorities
  1443.             must  take  additional steps  to ensure  an  adequate specification  for their
  1444.             intended purpose.   The following  items must be  supplied by the  Acquisition
  1445.             Authority.
  1446.  
  1447.             4.1.1  Protocol Selection
  1448.  
  1449.             The architecture described  in section 3 suggests a  range of protocol choices
  1450.             at different layers of  the OSI Reference Model.  A  subset of these protocols
  1451.             may adequately satisfy an individual acquisition requirement, and may be used.
  1452.             If  a subset  of the  protocols and  interface profiles  is chosen, it  is the
  1453.             Acquisition  Authority's responsibility to  ensure that all  paths through the
  1454.             architecture are complete, i.e., (1) that protocols from layer 1 through layer
  1455.             7 are included for  end systems and at least  layers 1 through 3 are  included
  1456.             for intermediate  systems,  and (2)  that  the appropriate  service  interface
  1457.             specifications for the selected  protocols are also included, as  indicated in
  1458.             section 4.1.2 below.
  1459.  
  1460.             With respect to selecting protocols, at least one lower layer technology  must
  1461.             be chosen,  i.e.,  CSMA/CD  (carrier  sense, multiple  access  with  collision
  1462.             detection) [NIST  1, 2; ISO 28,  29], Token Bus [NIST  1; ISO   28, 30], Token
  1463.             Ring [NIST 1; ISO 28, 31]; X.25 [NIST 1, 3; CCITT 1; ISO 8]; HDLC  LAP B point
  1464.             to point  (Pt-Pt) subnetwork [ISO 26] or ISDN [NIST  1, ANSI 1-3, CCITT 25-27,
  1465.             ISO 45].  Additional lower  layer  technologies may  be used  to meet  special
  1466.             requirements. The following protocol layers are mandatory for compliance  with
  1467.             GOSIP:   the connectionless  network layer  protocol, transport  class 4,  and
  1468.             session.  Transport class 0 and the Connection Oriented Network Service (CONS)
  1469.             [ISO 2,3] are mandated only in conjunction with public data network messaging;
  1470.             see  section 4.2.7.3,  Message  Handling Systems.   Presentation  protocol and
  1471.             association  control service elements are required for all applications except
  1472.             messaging.   At least one application  layer specific protocol  is required to
  1473.             support the  intended application.   For  example, if  messaging is  required,
  1474.             specify MHS;  if file transfer is required, specify  FTAM; and, if the Virtual
  1475.             Terminal Service is  required, specify  VT.   The provision of  the CONS,  for
  1476.             general use, and the Connectionless Transport Protocol (CLTP) are options that
  1477.             may be specified  in addition  to the GOSIP  mandatory Connectionless  Network
  1478.             Service  (CLNS)  and  Transport  (class  4),   respectively.    More  detailed
  1479.             specification guidance is provided in sections 4.2 and 4.3.
  1480.  
  1481.             4.1.2  Service Interface Requirements
  1482.  
  1483.             GOSIP mandates no service interface accessibility beyond that indicated in the
  1484.             Workshop Agreements; therefore, any additional service interface accessibility
  1485.             requirements must be clearly stated and mandated by the Acquisition Authority.
  1486.             For example, GOSIP mandates  no specific direct access to  transport services.
  1487.             If the Acquisition  Authority requires  direct access  to transport  services,
  1488.  
  1489.                                                   14
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.             such a requirement must be included in a solicitation.  The issues involved in
  1498.             determining such a requirement are complex.   Refer to the GOSIP Users'  Guide
  1499.             for a discussion of these issues.
  1500.  
  1501.             Should  the  Acquisition  Authority  not  request  direct  access  to  service
  1502.             interfaces, such access  might or might not  be provided at the  discretion of
  1503.             individual vendors.  For example,  some vendors may provide access to  session
  1504.             services, others may  provide access  to transport and  network services,  and
  1505.             still  others may  limit  access to  association  control services  only.   Of
  1506.             course, some vendors  may provide direct access  to service interfaces  at the
  1507.             human  user interface  only.   When  there  is no  requirement  for a  service
  1508.             interface between layers, vendors might  merge multiple layer implementations.
  1509.             Such a merger is often implemented to accrue performance benefits to the user.
  1510.  
  1511.             Should the Acquisition Authority  request direct access to a  specific service
  1512.             interface,  care  should  be  taken  to  specify the  general  functional  and
  1513.             operational  objectives   of  the  interface;  otherwise,   particular  vendor
  1514.             interface implementations might  or might not  meet user requirements.   While
  1515.             specifying the  general functional  and operational  objectives for a  service
  1516.             interface should enable the  vendor to meet a user's  functional requirements,
  1517.             such a specification will not ensure  portability of software, written to  the
  1518.             interface, across product  lines from multiple vendors.  Work  underway in the
  1519.             IEEE 1003.8  POSIX networking services  interface committee should  create, in
  1520.             the future,  a series  of service  interface specifications  that will  enable
  1521.             portability of  software written  to those  specifications.   In the  interim,
  1522.             Acquisition  Authorities requiring  service  interfaces  that enable  software
  1523.             portability  must include a very detailed and explicit interface specification
  1524.             within the solicitation.   Such a specification is difficult  and expensive to
  1525.             produce,  and will  limit the number  of vendors  that bid on  a solicitation.
  1526.             Thus, this practice is not recommended.  A more prudent course, at the present
  1527.             time, is  to specify the  general functional and  operational objectives of  a
  1528.             service interface, leaving implementation decisions to the vendor.
  1529.  
  1530.             4.1.3  Performance Requirements
  1531.  
  1532.             The Acquisition Authority must specify  performance requirements.  Performance
  1533.             of an  open  system is  a  function  of: 1)  the  source end  system,  2)  the
  1534.             destination  end system,  and 3)  the communications  links, subnetworks,  and
  1535.             intermediate systems between the two end systems.  The Acquisition Authority's
  1536.             best  strategy,  given  these  difficult-to-control  factors,  is  to  specify
  1537.             performance requirements  for the principal  operating environment of  the end
  1538.             system.  For  example, if the communicating  end systems will generally  be on
  1539.             the same token bus network, detailed  performance profiles should be developed
  1540.             for that environment.   If these systems must occasionally  communicate over a
  1541.             packet  data  network between  local  area networks  (LANs), then  a  test for
  1542.             correct  interoperation   in  this  occasional   environment,  without  strict
  1543.             performance requirements, should also be included.
  1544.  
  1545.             4.2  END SYSTEM SPECIFICATION
  1546.  
  1547.             4.2.1  Physical Layer
  1548.  
  1549.  
  1550.                                                   15
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.             GOSIP does not mandate any specific  physical interface standard. However, the
  1559.             Acquisition  Authority  must   specify  physical   layer  requirements  in   a
  1560.             solicitation.  The following interfaces are  recommended.  The three standards
  1561.             most  commonly  used  in  conjunction  with  X.25  are  Electronic  Industries
  1562.             Association (EIA) RS-232-C [EIA 1] for line speeds up to 19.2 kilobits/second,
  1563.             V.35 [CCITT 16] for line speeds above 19.2 kilobits/second, and EIA RS-530 for
  1564.             transfer  rates above 20  kilobits/second.   For IEEE  802 LANs,  the physical
  1565.             interface characteristics are identified in ISO 8802/3 for CSMA/CD, ISO 8802/4
  1566.             for token  bus,  and ISO  8802/5  for token  ring,  [ISO 29-31].    Additional
  1567.             specifications for these interfaces, including subsets, options, and parameter
  1568.             settings are included  in the Workshop Agreements  [NIST 1].  For  ISDN, GOSIP
  1569.             provides for  the basic  rate interface  (BRI) at  the S,  T, and U  reference
  1570.             points [ANSI 1-2]  and the  primary rate  interface (PRI) at  the U  reference
  1571.             point [ANSI 3].   The BRI provides a 16 kilobits/second signalling (D) channel
  1572.             and up to two 64 kilobits/second switched (B) channels.  The PRI provides a 64
  1573.             kilobits/second   signalling   (D)   channel  and   up   to   twenty-three  64
  1574.             kilobits/second switched (B) channels.  
  1575.  
  1576.             Other, non-proprietary, physical interface standards may be selected depending
  1577.             upon  unique  requirements   of  the   Acquisition  Authority;  however,   the
  1578.             Acquisition Authority must take special  care to ensure appropriate  operation
  1579.             of such  interfaces within a  procured system.   The Acquisition  Authority is
  1580.             advised to make a selection from the set of recommended physical interfaces.
  1581.  
  1582.             4.2.2  Data Link Layer
  1583.  
  1584.             The  data link layer protocols shall be  selected by the Acquisition Authority
  1585.             from among the following:  1) High Level Data Link Control  (HDLC) Link Access
  1586.             Procedure  B (LAP B),  in conjunction with  X.25 [NIST 1,3;  ISO 26] and Pt-Pt
  1587.             subnetworks; 2) ISO 8802/2 (LLC 1) in conjunction with ISO 8802/3, ISO 8802/4,
  1588.             or ISO 8802/5 [NIST  1; ISO 28], and 3) Q.921 (LAPD)  [CCITT 25] for operation
  1589.             on the ISDN  D channel and ISO 7776 (LAP B)  for operation on ISDN B channels.
  1590.             These protocols shall conform to the Workshop Agreements. 
  1591.  
  1592.  
  1593.  
  1594.  
  1595.             4.2.3  Network Layer Service
  1596.  
  1597.             For GOSIP end systems,  the connectionless network service (CLNS)  is mandated
  1598.             for  Government-wide  interoperability  and  provides  the required  means  of
  1599.             interconnecting logically  distinct local and  long-haul subnetworks.   When a
  1600.             GOSIP end system is  connected to a local  area or Pt-Pt subnetwork, the  CLNP
  1601.             end system to  intermediate system  (CLNP ES-IS) dynamic  routing protocol  is
  1602.             required.  The connection-oriented  network service is an option  available to
  1603.             GOSIP end  systems directly  connected to  an X.25  subnetwork or  ISDN.   The
  1604.             technology for providing  X.25 and ISDN subnetworks may be used to support the
  1605.             mandated CLNS  and the optional CONS; in either case certain subnetwork access
  1606.             protocols  are  required.    These  topics  are elaborated  in  the  following
  1607.             paragraphs.
  1608.  
  1609.             4.2.3.1  Connectionless Mode Network Service
  1610.  
  1611.                                                   16
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.             The Connectionless  Mode Network Service  (CLNS) shall be provided  by the ISO
  1621.             Connectionless Network Protocol  (CLNP) [NIST 1; ISO  4,7].  The CLNP  must be
  1622.             implemented  and used  for internetworking of  concatenated subnetworks.   For
  1623.             operation  on a single logical subnetwork, the  CLNP also must be implemented.
  1624.             When  an end system is connected to a  local area or Pt-Pt subnetwork the CLNP
  1625.             ES-IS protocol must be implemented and used.
  1626.  
  1627.             4.2.3.1.1  Provision of the Connectionless Network Service
  1628.  
  1629.             This service shall be  provided according to the Workshop  Agreements, section
  1630.             3.5, with the following modifications and additions:
  1631.  
  1632.             Add to the first bullet of section 3.5.1(2), the following:
  1633.  
  1634.                 o An End System  must provide a  configuration mechanism to  control
  1635.                   the value to be assigned to  the Lifetime parameter for PDUs which
  1636.                   it originates.  
  1637.  
  1638.             Replace  the  first bullet  of section  3.5.1(3)  Optional Functions  with the
  1639.             following:
  1640.  
  1641.                 o The use  of the  security parameter  shall be  in accordance  with
  1642.                   section 6  of this specification,  if required by  the Acquisition
  1643.                   Authority.
  1644.  
  1645.             Add as section 3.5.2(4): 
  1646.  
  1647.                 o The  CLNS  shall  be   provided  with  interfaces  to  the   1984  CCITT
  1648.                   Recommendation  X.25,  HDLC  LAP B  (ISO  7776),  ISO  8802.2 and  Draft
  1649.                   International Standard (DIS) 9574 (ISDN), as selected by the Acquisition
  1650.                   Authority.  When  interface to DIS 9574  is provided, the  provisions of
  1651.                   ISO 8878 are not used.
  1652.  
  1653.             Section 3.5.3 of the Workshop Agreements is to be implemented by those systems
  1654.             operating  over X.25.   Section  3.5.4  of the  Workshop Agreements  is  to be
  1655.             implemented by those systems operating over ISDN.
  1656.  
  1657.             4.2.3.1.2  Provision of The End System To Intermediate System Routing Service
  1658.  
  1659.             For end systems  connected to local area and Pt-Pt subnetworks, the end system
  1660.             to intermediate system (CLNP  ES-IS) routing service shall be  provided by the
  1661.             ES-IS  protocol ISO  9542 [ISO  44] implemented  as specified in  the Workshop
  1662.             Agreements section 3.8.1.   For end  systems connected to wide-area  networks,
  1663.             provision of an end  system to intermediate system routing service  is network
  1664.             specific.
  1665.  
  1666.             4.2.3.2  Connection-Oriented Network Service
  1667.  
  1668.             The  CONS is  an additional, optional  service that  may be specified  for end
  1669.             systems that are directly connected to X.25 wide area networks and ISDNs.  Use
  1670.             of  this  service  can,  under  certain   circumstances,  avoid  the  overhead
  1671.  
  1672.                                                   17
  1673.  
  1674.  
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.             associated with CLNP  and may permit interoperation  with end systems that  do
  1681.             not  comply with  GOSIP (i.e., do  not implement  CLNP).  When  an Acquisition
  1682.             Authority specifies the CONS option, CONS shall be provided by the X.25 Packet
  1683.             Level Protocol (PLP) [ISO 2].  The mapping of  the elements of the CONS to the
  1684.             elements of the X.25 PLP is according to ISO 8878 [ISO 8].  This service shall
  1685.             be provided as specified in section 3.6.1 of the Workshop Agreements  with the
  1686.             following modifications:
  1687.  
  1688.                 o Section 3.6.1.3 does not apply.
  1689.  
  1690.             When providing CONS  in an  ISDN, the considerations  for control  of B and  D
  1691.             channels shall  be provided by DIS 9574 [ISO  45] and implemented according to
  1692.             section 3.6.1.4 of the Workshop Agreements.
  1693.  
  1694.             (Note that use of  X.25 in GOSIP is consistent with  FIPS 100-1 which requires
  1695.             CCITT  X.25-1984, ISO 7776,  and ISO 8202  until January 1,  1993.  After that
  1696.             time, additional  items covered in CCITT  X.25-1988 are mandated by  FIPS 100-
  1697.             1.)
  1698.  
  1699.             4.2.3.3  Network Layer Protocol Identification
  1700.  
  1701.             OSI systems require  the ability to identify which OSI  protocols and services
  1702.             are  used  in  a  particular  instance  of communication.    These  rules  for
  1703.             identification are specified  in ISO DTR 9577  [ISO 43].  GOSIP  systems shall
  1704.             implement the protocol identification rules as specified in section 3.9.2.2 of
  1705.             the Workshop Agreements.
  1706.  
  1707.             4.2.3.4  Special Provisions For Integrated Services Digital Networks
  1708.  
  1709.             Integrated services  digital networks (ISDN) enables X.25  PLP data to be sent
  1710.             across the D channel, sharing the channel with signaling  data, and across a B
  1711.             channel.  The  Acquisition Authority must specify whether one or both of these
  1712.             capabilities are  required.   When  operation  of X.25  over  a B  channel  is
  1713.             selected,  the B channel can be provided as  a switched service or a permanent
  1714.             service.  The  Acquisition Authority must specify whether one or both of these
  1715.             capabilities are required.
  1716.  
  1717.             (Note that  at the present time switched access  to the B channel is available
  1718.             from most  ISDN vendors,  but not  in a  standard fashion;  thus, multi-vendor
  1719.             interoperability between  terminal equipment  and switching  equipment is  not
  1720.             widely available today. Work underway in the North American ISDN Implementors'
  1721.             Workshop  (IIW) is  expected to  improve  this situation  in the  future.   As
  1722.             appropriate IIW Agreements  are developed, and related ISDN FIPS are issued by
  1723.             NIST, GOSIP will be updated accordingly.)
  1724.  
  1725.             ISDN provides  the possibility of  a BRI  (16 Kbps  D-channel + 2  64 Kbps  B-
  1726.             channels)  or a  PRI  (64  Kbps  D-channel +  23  64  Kbps B-channels).    The
  1727.             Acquisition  Authority must  specify whether BRI  or PRI is  required for each
  1728.             system.   The BRI  service interface  might be  available at  the S,  T, or  U
  1729.             reference  point.    The  Acquisition  Authority  must  specify  the  physical
  1730.             interface required for each BRI system.
  1731.  
  1732.  
  1733.                                                   18
  1734.  
  1735.  
  1736.  
  1737.  
  1738.  
  1739.  
  1740.  
  1741.             ISDN B-channel services can be used by a GOSIP end system in any of six ways: 
  1742.  
  1743.                 1)   circuit-switched  access  to a  packet handler  integral  to an  ISDN
  1744.             switch; 
  1745.                 2)   circuit-switched access  to a  packet handler  separate from an  ISDN
  1746.             switch;
  1747.                 3)  circuit-switched access directly to another GOSIP end system, or GOSIP
  1748.             intermediate system; 
  1749.                 4)   dedicated circuit  access to  a packet  handler integral  to an  ISDN
  1750.             switch; 
  1751.                 5)   dedicated circuit  access to a  packet handler separate from  an ISDN
  1752.             switch, and 
  1753.                 6)    dedicated circuit  access  to  another GOSIP  end  system  or  GOSIP
  1754.             intermediate system.  
  1755.  
  1756.             The  Acquisition  Authority  must specify  the  B-channel  access capabilities
  1757.             required  for any  GOSIP  end  system intended  for  use  with ISDN  B-channel
  1758.             services.
  1759.  
  1760.             For ISDN physical layer  access at the S, T, and  U reference points, sections
  1761.             2.7.2.1  and 2.7.2.2 of  the Workshop Agreements  apply.  For  data link layer
  1762.             access on the D channel, section 2.7.2.4 of the Workshop 
  1763.  
  1764.  
  1765.             Agreements applies.  For  signaling on an  ISDN interface, section 2.7.2.5  of
  1766.             the Workshop Agreements applies.  For data  link layer access on a B  channel,
  1767.             section 2.7.2.6 of the Workshop Agreements applies.  The PLP for use on ISDN B
  1768.             and D channels  shall be implemented  as specified in  section 2.7.2.7 of  the
  1769.             Workshop Agreements.
  1770.  
  1771.             4.2.4  Transport Layer
  1772.  
  1773.             For GOSIP  end systems, the  connection-oriented transport service  (COTS), as
  1774.             provided   by   Transport   class   4,   is   mandated   for   Government-wide
  1775.             interoperability and is the required means  of providing a reliable end-to-end
  1776.             data  communications path between  end systems.   The connectionless transport
  1777.             service (CLTS) is an option available for GOSIP end systems.
  1778.  
  1779.             4.2.4.1  Connection-Oriented Transport Service
  1780.  
  1781.             The vendor shall  provide Transport class 4  [NIST 1; ISO 12,13]  according to
  1782.             section 4.5.1 of the Workshop Agreements, with the modifications and additions
  1783.             stated below.   Transport  class 0  [NIST 1;  CCITT 10,11]  is to  be used  as
  1784.             appropriate in  accordance with the  CCITT X.400 recommendations  (see section
  1785.             4.2.7.3 of this profile).
  1786.  
  1787.             Replace the sixth bullet of the Workshop Agreements section 4.5.1.2.1 with the
  1788.             following:
  1789.  
  1790.                 o It is recommended that  implementations not send user data  in the
  1791.                   CR  or CC TPDU.  Any user data received in a CR or CC TPDU will be
  1792.                   made available to the Transport Service user.
  1793.  
  1794.                                                   19
  1795.  
  1796.  
  1797.  
  1798.  
  1799.  
  1800.  
  1801.  
  1802.  
  1803.             Replace the seventh bullet  of the Workshop Agreements section  4.5.1.2.1 with
  1804.             the following:
  1805.  
  1806.                 o It is recommended that  implementations not send user data  in the
  1807.                   DR TPDU.    Any user  data received  in  a DR  TPDU will  be  made
  1808.                   available to the Transport Service user.
  1809.  
  1810.             Add, as the  thirteenth bullet of  the Workshop Agreements section  4.5.1.2.1,
  1811.             the following:
  1812.  
  1813.                 o Transport expedited shall be provided  as an optional service  for
  1814.                   the Transport Service user.
  1815.  
  1816.             In specifying operator and higher layer protocol access controls in transport,
  1817.             the Acquisition Authority  should be  guided by the  implementation guide  and
  1818.             military supplement [NIST 5,6].
  1819.  
  1820.             4.2.4.2  Connectionless Mode Transport Service
  1821.  
  1822.             The  Acquisition  Authority  may  specifiy  the optional  connectionless  mode
  1823.             transport service (CLTS) for GOSIP end  systems [ISO 46].  This option may  be
  1824.             specified only  as an addition  to the connection-oriented  transport service.
  1825.             Although  no GOSIP mandated protocols require  the CLTS, a number of non-GOSIP
  1826.             protocols widely available in  industry can use CLTS as an  efficient means of
  1827.             communicating  across local  area  networks.   The Acquisition  Authority must
  1828.             determine the need for CLTS to support non-GOSIP protocols.
  1829.  
  1830.             The CLTS  option shall  be implemented  using IS  8602 [ISO  47] according  to
  1831.             section 4.6 of the Workshop Agreements [NIST 1].  
  1832.  
  1833.             4.2.5  Session Layer
  1834.  
  1835.             The vendor shall provide the Session protocol  as specified in section 5.9 and
  1836.             section  5.12  of  the  Workshop  Agreements.    Application  layer  protocols
  1837.             determine the  session  layer  functional  units  needed  for  their  support.
  1838.             Current and future  needs should  be considered when  selecting Session  layer
  1839.             functional units. [NIST 1; ISO 14,15; CCITT 12,13].
  1840.  
  1841.             4.2.6  Presentation Layer
  1842.  
  1843.             The vendor shall provide the Presentation protocol as specified in section 5.8
  1844.             and section 5.12 of  the Workshop Agreements.  See References [NIST 1; ISO 20,
  1845.             21, 24, 25].
  1846.  
  1847.             4.2.7  Application Layer
  1848.  
  1849.             4.2.7.1  Association Control Service Elements (ACSE) 
  1850.  
  1851.             The  ACSE, as  specified  in section  5.5  and section  5.12  of the  Workshop
  1852.             Agreements, is  required to support  all applications except  Message Handling
  1853.             Systems.   See section 4.2.7.3 of  this profile.  See  References [NIST 1; ISO
  1854.  
  1855.                                                   20
  1856.  
  1857.  
  1858.  
  1859.  
  1860.  
  1861.  
  1862.  
  1863.             22-25].  Section 5.12.1.1 of the Workshop Agreements defines a fixed value for
  1864.             the Application Entity (AE) Title in order to satisfy the FTAM requirement for
  1865.             exchanging fields of  this type;   however, for  compatibility with  non-GOSIP
  1866.             systems,  and  to ease  compatibility  with  future versions  of  GOSIP, GOSIP
  1867.             systems  must  allow  locally  configurable  AE  Titles to  be  generated  and
  1868.             received.
  1869.  
  1870.             4.2.7.2  File Transfer, Access, and Management Protocol (FTAM)
  1871.  
  1872.             The following categories of FTAM systems are defined for procurement purposes:
  1873.             (1) limited-purpose systems,  and (2) full-purpose systems.   These categories
  1874.             are defined by  their support requirements given  below.  All FTAM  systems in
  1875.             these categories are  bound by the  language and conditions  for Phase 2  FTAM
  1876.             implementations contained in  section 9 of the Workshop  Agreements.  [NIST 1]
  1877.             (Hereafter section 9.)
  1878.  
  1879.             A limited-purpose FTAM system  provides the functions of simple  file transfer
  1880.             and management.  Such a  system must support at least Implementation  Profiles
  1881.             T1  (Simple  File Transfer)  and  M1 (Management)  as  defined  in section  9.
  1882.             Support requirements for  Implementation Profiles  are given in  Table 9.7  of
  1883.             section 9.   A full-purpose FTAM system  provides the functions  of positional
  1884.             file  transfer (including  simple  file  transfer),  simple file  access,  and
  1885.             management.  Such  a system must support  at least Implementation Profiles  T2
  1886.             (Positional File Transfer), A1  (Simple File Access), and M1  (Management), as
  1887.             these are  defined in section  9.  A  limited-purpose FTAM  system is able  to
  1888.             interoperate with  a full-purpose  FTAM system  at the  intersection of  their
  1889.             capabilities.
  1890.  
  1891.             FTAM implementations (whether full-purpose or  limited-purpose) can operate as
  1892.             an initiator of  remote file activity, as  a responder to requests  for remote
  1893.             file  activity,  or   as  both  initiator   and  responder.    Further,   FTAM
  1894.             implementations can operate as  senders (of data to receivers),  receivers (of
  1895.             data from  senders), or  as both.   Thus, any  of four  possible roles  may be
  1896.             assumed  as  follows: initiator-sendor,  initiator-receiver, responder-sender,
  1897.             and  responder-receiver.    The  Acquisition   Authority  must  determine  the
  1898.             requirements for each FTAM device and must specify such requirements in  terms
  1899.             of initiator, responder, sender, and receiver, as well as in terms of limited-
  1900.             purpose or full-purpose.
  1901.  
  1902.             4.2.7.3  Message Handling Systems
  1903.  
  1904.             The  vendor shall  provide  all Message  Transfer  Services and  Interpersonal
  1905.             Messaging Services specified in section 7 of the Workshop Agreements. [NIST 1]
  1906.             Communication between two Message Transfer Agents, one or both of which reside
  1907.             entirely and  exclusively within  a public  message domain  administered by  a
  1908.             public data network,  takes place as  specified by CCITT Recommendation  X.410
  1909.             (1984).   CCITT mandates  that transport class  0 and the  Connection Oriented
  1910.             Network Service (CONS) [ISO 2, 3]  be used by end systems when messaging  over
  1911.             public messaging domains on public data networks.   All end systems on private
  1912.             management domains must use transport class  4.  Private management domain end
  1913.             systems that  are also  connected to  public messaging  domains conforming  to
  1914.             CCITT Recommendation X.410 must also implement and use transport class  0 when
  1915.  
  1916.                                                   21
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.             acting  as  a messaging  relay  between the  two domains.    Specifically, the
  1925.             Message Transfer Agent  in the system connected to both the private and public
  1926.             messaging domain performs the relay; there is no transport relay involved. 
  1927.  
  1928.  
  1929.  
  1930.             4.2.7.4  Virtual Terminal (VT) Basic Class
  1931.  
  1932.             The following categories of  VT systems are defined for  procurement purposes:
  1933.             1) simple systems,  and 2)  forms capable systems.   All VT  systems in  these
  1934.             categories are bound by the language and conditions contained in section 14 of
  1935.             the Workshop Agreements.
  1936.  
  1937.             A  simple system  provides  the functions  of  a TTY  compatible  device.   It
  1938.             supports a  dialogue which is a  simple line or character  at a time.   Such a
  1939.             system uses the control character (single)  functions from the ASCII character
  1940.             set,  such  as "carriage  return," "form  feed,"  "horizontal tab,"  and "back
  1941.             space."   A simple  system supports  the TELNET  profile specified  in section
  1942.             14.8.1  of  the  Workshop  Agreements.     The  TELNET  profile  requires  the
  1943.             Asynchronous mode (A-mode) of operation (i.e., no token handling protocols are
  1944.             needed) and specifies simple delivery control.
  1945.  
  1946.             A forms-capable  system is intended  to support forms-based  applications with
  1947.             local entry and  validation of data by  the terminal system.   A forms-capable
  1948.             system  supports  functions such  as  "cursor movement,"  "erase  screen," and
  1949.             "field  protection."    A  forms-capable  system  supports  the forms  profile
  1950.             specified in section  14.8.3 of  the Workshop Agreements.   The forms  profile
  1951.             requires  the  Synchronous mode  (S-mode)  of operation  and  specifies simple
  1952.             delivery control.
  1953.  
  1954.             The Basic Class VT International Standard [ISO 32] specifies three negotiation
  1955.             options which are independent of the  VT profiles.  These are No  Negotiation,
  1956.             Switch Profile, and  Multiple Interaction  Negotiation.  Multiple  Interaction
  1957.             Negotiation  is  not addressed  by  the  Workshop Agreements,  but  any system
  1958.             claiming  support  of this  negotiation option  must  also support  the Switch
  1959.             Profile and  No Negotiation  options.   Any system  supporting Switch  Profile
  1960.             Negotiation must also support the  No Negotiation option.  Seven  bit USASCII,
  1961.             as  well  as the  International  Reference  Version (IRV)  of  ISO-646 graphic
  1962.             repertoires, must be supported by both simple and forms capable systems.
  1963.  
  1964.             4.2.8  Exchange Formats
  1965.  
  1966.             Exchange formats are  not OSI standards.   They are included in  GOSIP because
  1967.             the information that they describe can be transported by  the OSI FTAM and MHS
  1968.             protocols either as the  content of a file or  as the body part of  a message.
  1969.             The  GOSIP  contains only  that information  about  exchange formats  that are
  1970.             required  to  provide this  capability.   For  detailed specifications  on the
  1971.             exchange formats, consult the appropriate standards documents  or the Workshop
  1972.             Agreements.   
  1973.  
  1974.             Version 2  of GOSIP includes information on how  to identify and transport the
  1975.             ODA exchange format.  Future versions of GOSIP will include information on how
  1976.  
  1977.                                                   22
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.  
  1985.             to  identify  and transport  additional  formats  such  as  Computer  Graphics
  1986.             Metafile  (CGM) and the Standard General  Markup Language (SGML).  For further
  1987.             details, see Appendix 4.  
  1988.  
  1989.             ODA information can also  be transported by other mechanisms which are outside
  1990.             the scope of the GOSIP.
  1991.  
  1992.             4.2.8.1  Office Document Architecture (ODA)
  1993.  
  1994.             The ODA Standard [ISO 36-42, CCITT  17-24] specifies rules for describing  the
  1995.             logical and  layout structures of  documents as  well as rules  for specifying
  1996.             character, raster, and geometric content of documents, thus, providing for the
  1997.             interchange  of  complex documents.    The  interchanged documents  may  be in
  1998.             formatted  form (i.e.,  for  presentation such  as  printing, displaying),  in
  1999.             processable  form  (i.e.,  for  further  processing  such as  editing)  or  in
  2000.             formatted  processable  form   (i.e.,  for   both  presentation  and   further
  2001.             processing).
  2002.  
  2003.             To transfer  an ODA  file, the  services provided by  either the  MHS or  FTAM
  2004.             application can be used.
  2005.             If the MHS application is used, OdaBodyParts are encoded for transmission over
  2006.             a  CCITT X.400-1984  service as  a  single body  part with  tag 12  in  the P2
  2007.             protocol.
  2008.  
  2009.                 Oda [12] IMPLICIT OCTETSTRING
  2010.  
  2011.             The content of  the OCTETSTRING  is a SEQUENCE  of OdaBodyPart Parameters  and
  2012.             OdaData components with a value of type OdaBodyPart.
  2013.  
  2014.                 OdaBodyPart :: = SEQUENCE {
  2015.                   OdaBodyPart Parameters,
  2016.                   OdaData             }
  2017.  
  2018.             The  OdaBodyPart  Parameters  component  is  a SET  containing  the  document-
  2019.             application-profile and the document-architecture-class identifiers
  2020.  
  2021.                 OdaBodyPart Parameters :: = SET {
  2022.                   document-application profile [0] IMPLICIT OBJECT IDENTIFIER
  2023.                   document-architecture-class [1] IMPLICIT INTEGER {
  2024.                               formatted (0),
  2025.                               processable (1),
  2026.                               formatted-processable (2) }}
  2027.  
  2028.             The OdaData component is a SEQUENCE  of Intercharge-Data Element as defined by
  2029.             IS 8613-5 [ISO 39]
  2030.  
  2031.                   OdaData :: = SEQUENCE of Interchange-Data-Element
  2032.  
  2033.             In the P1 protocol, both the undefined bit (bit 0) and the ODA bit (bit 10) of
  2034.             the Encoded Information Type  must be set when an  ODA document is present  in
  2035.             P2.
  2036.  
  2037.  
  2038.                                                   23
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.             When using FTAM  to transfer an  ODA file, the  FTAM-3 (ISO FTAM  unstructured
  2047.             binary)  document type should be specified;  however, since files that are not
  2048.             ODA files  can have  the same  document type,  it is  left up to  the user  of
  2049.             application programs  that remotely  access files  using FTAM to  know that  a
  2050.             given file contains ODA information.
  2051.  
  2052.             4.3  INTERMEDIATE SYSTEM SPECIFICATION
  2053.  
  2054.             Intermediate  systems  shall operate  in connectionless  mode.   That  is, the
  2055.             connectionless  network protocol is used  regardless of whether the underlying
  2056.             technology  operates  in   connectionless  (e.g.,  CSMA/CD,  token   ring)  or
  2057.             connection-oriented (e.g., X.25, LAP B) mode; however, the connectionless mode
  2058.             need not be  used to interconnect  X.25 subnetworks to  form a single  logical
  2059.             subnetwork.  Also note that local area network bridges may be employed to form
  2060.             a single logical subnetwork.
  2061.  
  2062.             Intermediate systems may use  any combination of the lower  layer technologies
  2063.             as  specified in the  above sections  of this  profile: 4.2.1  Physical Layer,
  2064.             4.2.2  Data  Link Layer,  and  4.2.3 Network  Layer.   That  is,  agencies may
  2065.             interconnect local and wide area networks.   Implementation profiles for these
  2066.             protocols are contained in the Workshop  Agreements and are referenced in  the
  2067.             above  sections   of  this   profile.     Implementation  specifications   for
  2068.             connectionless-mode  intermediate systems  are  given in  section  3.5 of  the
  2069.             Workshop Agreements.  
  2070.  
  2071.             Addressing structure  and Address  Registration Authorities  are specified  in
  2072.             section 5 of this profile.
  2073.  
  2074.             A system that serves as both  end system and intermediate system must  satisfy
  2075.             the mandatory requirements of sections 4.2 and 4.3 of this profile.
  2076.  
  2077.  
  2078.  
  2079.  
  2080.  
  2081.  
  2082.  
  2083.  
  2084.  
  2085.  
  2086.  
  2087.  
  2088.  
  2089.  
  2090.  
  2091.  
  2092.  
  2093.  
  2094.  
  2095.  
  2096.  
  2097.  
  2098.  
  2099.                                                   24
  2100.  
  2101.  
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.                                       5.  ADDRESSING REQUIREMENTS
  2108.  
  2109.  
  2110.             5.1  NETWORK LAYER ADDRESSING AND ROUTING
  2111.  
  2112.             This  section   specifies  the  Network   Layer  addressing  scheme   and  its
  2113.             administrative  and  routing  implications.   It  also  identifies authorities
  2114.             responsible for the administration  of the scheme and how  subauthorities will
  2115.             be assigned and which responsibilities shall be delegated to them.
  2116.  
  2117.             5.1.1    NSAP Address  Administration,  Routing  Structures and  NSAP  Address
  2118.             Structure
  2119.  
  2120.             Network Service Access  Point (NSAP)  addresses specify the  points where  the
  2121.             communication capability of the  Network Layer (i.e., the Network  Service) is
  2122.             made available to its users.   In effect they address the direct users  of the
  2123.             Network Service, normally transport entities.  The semantics of NSAP addresses
  2124.             are encoded into Network  Protocol Address Information (NPAI) and  conveyed in
  2125.             the appropriate protocol data units (PDUs) between protocol entities providing
  2126.             the Network Service.
  2127.  
  2128.             The basic principles of Network Layer addressing,  as defined in Addendum 2 to
  2129.             the Network service definition [ISO 5], include:
  2130.                                         
  2131.                 o NSAP  address   administration  is   based  on   the  concept   of
  2132.                   hierarchical Addressing Domains.  An Addressing Domain is a set of
  2133.                   addresses interrelated by virtue of being administered by a common
  2134.                   authority.  The term authority refers to the entity that specifies
  2135.                   the structure  and ensures  the uniqueness  of identifiers  in the
  2136.                   associated  domain.  In  practice the structure  of NSAP addresses
  2137.                   reflects this administrative  hierarchy in that,  at any level  of
  2138.                   the  hierarchy,  an  initial  part  of the  address  unambiguously
  2139.                   identifies the Addressing (sub) Domain.
  2140.                    
  2141.                         o     The  first   three  levels  of   the  NSAP
  2142.                               addressing  domain  are  standardized  and
  2143.                               result in  the NSAP  address structure  in
  2144.                               Figure  5.1.1.   The  Initial Domain  Part
  2145.                               (IDP)  of  the  address  consists  of  two
  2146.                               parts, the Authority and Format Identifier
  2147.                               (AFI)  and  the Initial  Domain Identifier
  2148.                               (IDI).  The  AFI specifies  the format  of
  2149.                               the IDI, the authority that is responsible
  2150.                               for allocating IDI values, and the  syntax
  2151.                               used to represent the Domain Specific Part
  2152.                               (DSP).  The  IDI is interpreted  according
  2153.                               to  the  value of  the  AFI and  its value
  2154.                               identifies the  authority responsible  for
  2155.                               the  structure  and   assignment  of   DSP
  2156.                               values.  The DSP is allocated and assigned
  2157.                               by  the  authority  specified by  the  IDP
  2158.                               part.
  2159.  
  2160.                                                   25
  2161.  
  2162.  
  2163.  
  2164.  
  2165.  
  2166.  
  2167.  
  2168.              
  2169.  
  2170.                                                           ZDDDDDDDDDDDDDDDD?
  2171.                                                           3       IDP      3
  2172.                                                           CDDDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDD?
  2173.                                   ISO/CCITT NSAP ADDRESS  3  AFI   3  IDI  3       DSP               3
  2174.                                                           @DDDDDDDDADDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDY
  2175.  
  2176.                                                                 Figure 5.1.1  NSAP Address Structure
  2177.                             
  2178.  
  2179.             The National Institute of Standards and  Technology (NIST) has been designated
  2180.             as  the authority to administer the  addressing domain identified by IDI value
  2181.             0005 under AFI 47.  The AFI value of decimal 47 specifies that the IDI part is
  2182.             interpreted as a  four decimal digit  International Code Designator (ICD)  and
  2183.             that the DSP has a binary abstract syntax.  ICDs are allocated and assigned by
  2184.             ISO [ISO 27] and identify international organizations that are the authorities
  2185.             for address administration for an addressing subdomain.
  2186.  
  2187.             The addressing domain identified by ICD 0005 shall be available for use by all
  2188.             of the Federal Government.  The NIST shall specify the structure and semantics
  2189.             of the DSP associated with ICD 0005 and delegate the task of administering the
  2190.             assignment of DSP  values to the General Services Administration (GSA).   This
  2191.             is summarized in Figure 5.1.2.
  2192.                                            
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.                                                                                26
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.                                                               ZDDDDDDDDDDDDDD?
  2230.                                                               3      IDP     3
  2231.                                                               CDDDDDDDBDDDDDDEDDDDDDDDDDDDDDDDDDDD?
  2232.                                   ISO/CCITT NSAP Address      3 AFI   3 IDI  3       DSP          3
  2233.                                                               CDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
  2234.                                   Fed. Govt. NSAP Address     3  47   3 0005 3structure specified 3
  2235.                                                               3       3      3by  GOSIP           3
  2236.                                                               @DDDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
  2237.  
  2238.                                       Figure 5.1.2  The NIST ICD Addressing Domain
  2239.  
  2240.  
  2241.             NSAP addresses,  encoded as NPAI  in appropriate NPDUs,  serve as  the primary
  2242.             input to the routing and relaying functions of protocol entities providing the
  2243.             Network  Service.   As  such,  the semantics  of  NSAP addresses  must  convey
  2244.             information required for routing as well as address administration.
  2245.  
  2246.             The basic  principles of Network Layer routing, as  defined in the OSI Routing
  2247.             Framework [ISO 48], include:
  2248.  
  2249.                 o The  global OSI environment will consist of a number of Administrative
  2250.                   Domains.   An  Administrative Domain consists  of a collection  of End
  2251.                   Systems  (ESs)   and  Intermediate  Systems   (ISs),  and  subnetworks
  2252.                   operated  by  a  single  entity  or  Administrative  Authority.    The
  2253.                   Administrative  Authority is  responsible for the  organization of ESs
  2254.                   and ISs into  Routing Domains; the  further structuring and assignment
  2255.                   of  NSAP addresses;  the policies that govern  the information that is
  2256.                   collected  and  disseminated both  internally  and externally  to  the
  2257.                   Administrative  Domain; and,  the establishment of  subdomains and the
  2258.                   corresponding delegation of responsiblities.
  2259.  
  2260.                   o     A Routing  Domain is  a set  of ESs  and  ISs which  operate
  2261.                         according to the same routing procedures and which is wholly
  2262.                         contained   within  a  single  Administrative  Domain.    An
  2263.                         Administrative  Authority   may  delegate   to  the   entity
  2264.                         responsible  for a  Routing Domain  the  responsibilities to
  2265.                         further  structure   and   assign  NSAP   addresses.     The
  2266.                         hierarchical   decomposition   of   Routing   Domains   into
  2267.                         subdomains may greatly reduce the  resources required in the
  2268.                         maintenance, computation and storage of routing information.
  2269.  
  2270.              
  2271.             This GOSIP makes provisions  for the establishment of  Administrative Domains,
  2272.             Routing Domains  and one  level of  routing subdomains  (called Areas).   This
  2273.             decomposition   of  the   routing  environment   allows,  where   appropriate,
  2274.             administrative entities to  request the delegation  of responsibility for  the
  2275.             organization  and  administration  of  their systems  and  subnetworks.    The
  2276.             provision of two levels of routing  structures within an Administrative Domain
  2277.             will allow Administrative Authorities to  engineer routing configurations that
  2278.             best serve their individual needs.
  2279.  
  2280.             Figure  5.1.3 depicts  the GOSIP NSAP  address structure.   This  structure is
  2281.  
  2282.                                                   27
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.             mandatory for addresses allocated from the ICD 0005 addressing domain.
  2291.              
  2292.  
  2293.  
  2294.                  ZDDDDDDDDDDDDDD?
  2295.                  3     IDP      3                                                                                              
  2296.                  CDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
  2297.                  3 AFI  3  IDI  3                                    DSP                                                       3     
  2298.                  CDDDDDDEDDDDDDDEDDDDDDDDDDDBDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDD4
  2299.                  3 47   3 0005  3    DFI    3  Admin Author.  3   Reserved  3 Routing Domain   3 Area 3    System     3  NSel  3
  2300.                  CDDDDDDEDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDD4
  2301.          Octets  3  1   3   2   3     1     3        3        3      2      3         2        3   2  3       6       3    1   3
  2302.                  @DDDDDDADDDDDDDADDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDADDDDDDDDDDDDDDDADDDDDDDDY    
  2303.                                     
  2304.                        Figure 5.1.3  GOSIP NSAP Address Structure                    
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.  
  2315.  
  2316.  
  2317.  
  2318.  
  2319.  
  2320.  
  2321.  
  2322.  
  2323.  
  2324.  
  2325.  
  2326.  
  2327.  
  2328.  
  2329.  
  2330.  
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.                                                      28
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.             The  DSP  Format Identifier  (DFI)  specifies  the  structure,  semantics  and
  2352.             administration requirements associated  with the remainder  of the DSP.   This
  2353.             field provides for  graceful support of future DSP  structures should the need
  2354.             arise.   Currently,  only one DSP  format (DFI=10000000) is  defined under ICD
  2355.             0005.  The remainder of this section describes this DSP format.
  2356.  
  2357.             The Administrative Authority field  identifies the entity that  is responsible
  2358.             for the  organization  of ISs  and ESs  into Routing  Domains  and Areas;  the
  2359.             allocation and  assignment  of  the remaining  portion  of the  DSP;  and  the
  2360.             policies that govern the  dissemination of information within and  external to
  2361.             the Administrative Domain.   Note that it is unlikely  that a large number  of
  2362.             Federal  Government  organizations  will establish  their  own  Administrative
  2363.             Domains.   Instead,  it  is more  likely that  Administrative Domains  will be
  2364.             established  for  collective  organizations  that autonomously  operate  large
  2365.             inter-networks  and  that  individual organizations  would  correspondingly be
  2366.             delegated authority for Routing Domains or Areas.
  2367.  
  2368.             The  Reserved field is  positioned to be  available for  encoding higher level
  2369.             routing structures above those  of the routing domain or to be  used to expand
  2370.             either the Administrative Authority or the Routing Domain fields in future DSP
  2371.             formats should the need arise.  
  2372.  
  2373.             The  Routing  Domain  field  identifies  a  unique Routing  Domain  within  an
  2374.             Administrative Domain.
  2375.  
  2376.             The Area field identifies a unique subdomain of the Routing Domain.
  2377.  
  2378.             The System field identifies  a unique system (ES  or IS) within an Area.   The
  2379.             format, value, structure and meaning of  this field is left to the  discretion
  2380.             of its administrator.  
  2381.  
  2382.             The NSAP Selector field identifies a direct user of the Network Layer service,
  2383.             usually a Transport entity.  (The NSAP Selector may also identify other direct
  2384.             users  of  the Network  Service if  required by  the Acquisition  Authority.) 
  2385.             GOSIP allows a  system administrator  to configure NSAP  Selector-to-Transport
  2386.             entity  mappings because, for example, several transport entities may co-exist
  2387.             in some systems.
  2388.  
  2389.             5.1.2  NSAP Address Registration Authorities
  2390.  
  2391.             This section names  the GSA as  the GOSIP Address Registration  Authority, and
  2392.             specifies how  subauthorities shall  be assigned,  and which  responsibilities
  2393.             transfer to them.
  2394.              
  2395.             Under its delegated authority as Address  Registration Authority for ICD 0005,
  2396.             GSA shall, upon request, assign, maintain, and publicize unique Administrative
  2397.             Authority identifiers for  Federal Government  entities that require  distinct
  2398.             Administrative Domains.  Contact GSA at: 
  2399.  
  2400.                   Telecommunications Customer Requirements Office
  2401.                   U. S. General Services Administration
  2402.                   IRMS
  2403.  
  2404.                                                   29
  2405.  
  2406.  
  2407.  
  2408.  
  2409.  
  2410.  
  2411.  
  2412.                   Office of Telecommunications Services
  2413.                   18th & F Sts. N.W.
  2414.                   Washington, D. C. 20405
  2415.  
  2416.             for  the  procedures  for  requesting  the  assignment  of  an  Administrative
  2417.             Authority identifier.  They are also included in Version 2 of the GOSIP User's
  2418.             Guide.
  2419.  
  2420.             5.1.2.1  Responsibilities Delegated by NIST
  2421.                
  2422.             The management responsibilities delegated by the NIST, via the GSA, to Federal
  2423.             Government entities issued  an Administrative  Authority identifier under  ICD
  2424.             0005 are given below.
  2425.  
  2426.                   o     The entity must  designate and  register with the  GSA a  specific
  2427.                         point of contact for its Administrative Authority.
  2428.  
  2429.                   o     The  entity  must  ensure  that   procedures  exist  to  establish
  2430.                         appropriate  routing  structures  and to  delegate,  if  required,
  2431.                         responsibliities  to  the  administrators  of  individual  Routing
  2432.                         Domains or Areas.
  2433.                   
  2434.                   o     The entity  must ensure that  addresses are assigned  uniquely and
  2435.                         are kept current and accurate.
  2436.  
  2437.                   o     The entity  must ensure that  policies are defined  and procedures
  2438.                         exist  for making addresses and routing information known to other
  2439.                         administrative domains.
  2440.  
  2441.                   o     The  entity  may, on  a  voluntary basis,  supply such
  2442.                         information to the GSA for government-wide compilation
  2443.                         and dissemination.   The GOSIP  Users' Guide [NIST  7]
  2444.                         lists  the  factors  that  Administrative  Authorities
  2445.                         should consider before requesting this service and the
  2446.                         procedures to be followed if the service is required.
  2447.  
  2448.             5.1.3  GOSIP Routing Procedures
  2449.  
  2450.             This  GOSIP  specifies  dynamic  routing   procedures  for  the  exchange   of
  2451.             configuration information between  ESs and  ISs connected via  local area  and
  2452.             point to point (pt-pt) subnetworks and hierarchical, static routing procedures
  2453.             for  the  establishment  of routing  information  among  ISs.   These  routing
  2454.             procedures  shall  be  provided  according  to  section 3.8  of  the  Workshop
  2455.             Agreements, with the following additions after the paragraph of section 3.8.2:
  2456.  
  2457.                   o     The Routing Information Base (RIB) shall be capable of associating
  2458.                         arbitrary sets of NSAPs, described  as NSAP address prefixes, with
  2459.                         next hop  forwarding information for use by the ISO 8473 Route PDU
  2460.                         Function.  In addition,  the RIB must be  capable of supporting  a
  2461.                         default  entry  that   is  used  in  forwarding   PDUs  containing
  2462.                         destination  NSAP  addresses  that  do not  match  any  other  RIB
  2463.                         entries.
  2464.  
  2465.                                                   30
  2466.  
  2467.  
  2468.  
  2469.  
  2470.  
  2471.  
  2472.  
  2473.  
  2474.             Nonstandard dynamic routing procedures, in addition to the static capabilities
  2475.             specified above,  may be  used to  establish RIBs  within ISs  in the  interim
  2476.             period while OSI IS-IS dynamic routing  protocols are still under development.
  2477.             It  should  be  noted that  the  GOSIP  supported routing  structures  and DSP
  2478.             addressing structure are in alignment with  the OSI IS-IS intra-domain routing
  2479.             protocol [ISO 49] currently under development and that  later versions of this
  2480.             profile will mandate the use of standardized OSI IS-IS routing protocols. 
  2481.  
  2482.             The routing procedures  required for  GOSIP systems to  communicate with  non-
  2483.             GOSIP OSI-compliant  systems are discussed  in Version  2 of the  GOSIP User's
  2484.             Guide.
  2485.  
  2486.             5.2  UPPER LAYERS ADDRESSING
  2487.  
  2488.             The  following  sections provide  guidance on  certain upper  layer addressing
  2489.             issues.
  2490.                                  
  2491.             5.2.1  Address Structure
  2492.  
  2493.             The  address  structure  for  the  Session  Service Access  Point  (SSAP)  and
  2494.             Transport Service Access  Point (TSAP) Selector is two octets  for each field,
  2495.             encoded in binary  as shown on  Fig. 5.2.1.  Other  lengths conforming to  the
  2496.             limits specified in the Workshop Agreements, may be assigned by an  end system
  2497.             administrator.
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522.  
  2523.  
  2524.  
  2525.  
  2526.                                                   31
  2527.  
  2528.  
  2529.  
  2530.  
  2531.  
  2532.  
  2533.  
  2534.                                                PSAP            SSAP            TSAP 
  2535.                                            ZDDDDDDDDDDDD?  ZDDDDDDDDDDDD?  ZDDDDDDDDDDDD?                    
  2536.                                            3   binary   3  3   binary   3  3   binary   3                    
  2537.                                            @DDDDDDDDDDDDY  @DDDDDDDDDDDDY  @DDDDDDDDDDDDY                        
  2538.                                              2 octets         2 octets         2 octets
  2539.  
  2540.                                             Figure 5.2.1  Upper Layers Address Structure
  2541.  
  2542.             5.2.2  Address Assignments
  2543.  
  2544.             Service access point (SAP) selectors specify the addresses of standard service
  2545.             interfaces.  Values  are assigned by an  end system administrator and  must be
  2546.             configurable  in  GOSIP end  systems.   T-selectors  and S-selectors  are each
  2547.             encoded as  a string  of octets.   The  octet string  may be  specified as  an
  2548.             unsigned integer; if so,  the high order octet precedes low  order octets.  P-
  2549.             selectors are encoded in Abstract Syntax  Notation (ASN).1 type OCTETSTRING as
  2550.             per the Presentation protocol specification [ISO 21]. 
  2551.  
  2552.             The  Application  Context Name  can  be  used to  distinguish  the Application
  2553.             entities  that use the common  application services of  ACSE.  The Application
  2554.             Context Names  for FTAM and VT, as specified  in sections 5.12.1.1 and section
  2555.             5.12.1.4 of the Workshop Agreements, are  "ISO FTAM" and "ISO VT."  Note  that
  2556.             applications which  require  additional Application  Context  information  may
  2557.             define them, even if they make use of FTAM and/or VT.
  2558.  
  2559.             5.2.3  Address Registration
  2560.  
  2561.             As an interim  measure, until Directory Service implementations are available,
  2562.             federal agencies  that  wish to  have  their  PSAP address  (upper  layer  SAP
  2563.             selector  values  plus full  NSAP address)  accessible  to other  agencies may
  2564.             register  these  addresses  with  GSA.    GSA  shall  catalog,  maintain,  and
  2565.             disseminate these addresses.  
  2566.  
  2567.             5.3  IDENTIFYING APPLICATIONS
  2568.  
  2569.             5.3.1  FTAM and File Transfer User Interface Identification
  2570.  
  2571.             The FTAM service definition [ISO 18] includes an optional parameter called the
  2572.             initiator  identity.   GOSIP  recommends the  use of  this  parameter in  FTAM
  2573.             implementations to identify users  of the service.  Generally,  an identifying
  2574.             name or group  of names is  provided in this field.   The name  identifies the
  2575.             particular  user  in  such a  way  that  two different  users  may  readily be
  2576.             distinguished.   In the  standard there  are no  restrictions on  what may  be
  2577.             included.   The initiator identity  is encoded as  an ASN.1 [ISO  25] variable
  2578.             length graphic string with characters from the ISO646 set [ISO 9]. These names
  2579.             are normally inserted  as needed  by end  systems, and this  profile makes  no
  2580.             provision for registration.  The content is system-dependent.
  2581.  
  2582.             5.3.2  MHS and Message User Interface Identification
  2583.  
  2584.             The  MHS Recommendations [CCITT  2-9] identify  a user  to a  Message Transfer
  2585.             Agent by means of a parameter called the Originator/Recipient Name (O/R Name).
  2586.  
  2587.                                                   32
  2588.  
  2589.  
  2590.  
  2591.  
  2592.  
  2593.  
  2594.  
  2595.             The O/R Name is encoded  as a set of attributes describing the  originator and
  2596.             receiver of  the  message.   The attributes  which must  be  supported by  all
  2597.             implementations are the country name, the administration  name, private domain
  2598.             name,  organization  name,  organizational  units,  and  personal  name.   The
  2599.             administration name  attribute shall  contain one  blank  when the  originator
  2600.             and/or recipient are  attached only to a  private domain.  The  private domain
  2601.             name attribute must also be supported by all  implementations, and be included
  2602.             when the originator and/or the recipients are located within different private
  2603.             domains.  This information is summarized in Table 5.3.
  2604.  
  2605.  
  2606.  
  2607.  
  2608.  
  2609.  
  2610.                                   ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
  2611.                                   3            Attribute              Maximum ASCII Character Length      3
  2612.                                   3                                                                       3   
  2613.                                   3          country name                           3                     3  
  2614.                                   3          administration name                   16                     3 
  2615.                                   3          private domain name                   16                     3 
  2616.                                   3          organization name                     64                     3   
  2617.                                   3          sequence of org. units                32 each                3 
  2618.                                   3          personal name                         64                     3
  2619.                                   @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY     
  2620.                                            Table 5.3  Required O/R Name Attributes                 
  2621.  
  2622.             Private messaging systems within the government shall be capable of routing on
  2623.             the  administration  name,   private  domain   name,  organization  name   and
  2624.             organizational unit attributes taken in their  hierarchical order.  They shall
  2625.             also  be  capable of  routing  on or  delivering  based on  the  personal name
  2626.             attribute; that is, they  shall act as Class 2  or Class 3 MTAs as  defined in
  2627.             section  7.7.3.3   of  the   Workshop  Agreements.     The   General  Services
  2628.             Administration  (GSA)  shall   be  the  Address  Registration   Authority  for
  2629.             organization names.  GSA shall delegate  Address Registration Authority to the
  2630.             organization  indicated by the  organization name to  assign organization unit
  2631.             and personal names.  In assigning the organizational unit personal name space,
  2632.             the  Address  Registration Authorities  shall  follow  the same  rules  stated
  2633.             earlier for NSAP addresses, except that organizational unit and personal names
  2634.             are not registered with GSA.   Typically, a unique personal name is  a surname
  2635.             or surname followed  by given name,  but it could also  be an identifier  of a
  2636.             particular office within the organization unit.  
  2637.  
  2638.             CCITT assigns country name  and administration name to public  message service
  2639.             providers.  Administrations  assign private domain names to  private messaging
  2640.             systems  that   wish  to   interoperate  across   the  administration.     The
  2641.             administration may also provide a registration service for government assigned
  2642.             organization names that wish to interoperate across  or between administrative
  2643.             domains.  A  method for assigning  private domain names in  the absence of  an
  2644.             administrative  name is  given in section  8.4.2 of  Version 2.0 of  the GOSIP
  2645.             User's Guide.
  2646.              
  2647.  
  2648.                                                   33
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654.  
  2655.  
  2656.                                          6.  SECURITY OPTIONS
  2657.  
  2658.              
  2659.             Security is  of fundamental  importance  to the  acceptance  and use  of  open
  2660.             systems in the  U.S. Government.  Part  2 of the Open  Systems Interconnection
  2661.             reference model (Security  Architecture) is now an  International Standard (IS
  2662.             7498/2).  The standard describes  a general architecture for security in  OSI,
  2663.             defines a set of security services that may be supported within the OSI model,
  2664.             and  outlines  a  number of  mechanisms  than  can be  used  in  providing the
  2665.             services.    However,  no  protocols,  formats  or  minimum  requirements  are
  2666.             contained in the standard. 
  2667.              
  2668.             The text below describes one security option that may  be optionally specified
  2669.             when security  services  are incorporated  in  the OSI  network  layer.   This
  2670.             chapter does not describe at this time a complete set of security options that
  2671.             a user might desire  nor a description of the security  services and protocols
  2672.             that are associated with  the specified parameter.  It is a parameter that has
  2673.             been  identified  as   being  needed  if  certain  security   services  (e.g.,
  2674.             confidentiality, access control) are  incorporated in the network layer.   The
  2675.             parameter should be used where required, but this chapter should be considered
  2676.             as a  placeholder for  future security  specifications.   Appendix 1  provides
  2677.             further  information  on what  specifications  are considered  needed  for OSI
  2678.             security. 
  2679.              
  2680.             As defined by  ISO, security features  are considered both implementation  and
  2681.             usage options.  An organization desiring  security in a product that is  being
  2682.             purchased in accordance with  this profile must specify the  security services
  2683.             required,  the  placement of  the services  within  the OSI  architecture, the
  2684.             mechanisms to provide the services  and the management features required.   An
  2685.             acquisition authority desiring Connectionless Network Protocol (CLNP) security
  2686.             should specify the  following described security  option(s).  When  specifying
  2687.             the  CLNP  security option,  the acquisition  authority  must ensure  that all
  2688.             necessary Security Format Codes are provided. 
  2689.  
  2690.             6.1  REASON FOR DISCARD PARAMETERS 
  2691.              
  2692.             The implementation  of the  security option  requires assigning new  parameter
  2693.             values to the Reason for Discard parameter  in the CLNP Error Report PDU.  The
  2694.             first octet of the parameter value contains an error type code as described in
  2695.             IS 8473.  Values beyond those assigned in the standard are shown in Table 6.1.
  2696.             The second octet  of the Reason for Discard parameter value either locates the
  2697.             error in  the discarded  PDU or contains  the value  zero as described  in the
  2698.             standard. 
  2699.                                                              
  2700.                                                                                                             
  2701.                                   ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDD?
  2702.                                   3       Parameter Values              3               3                     3
  2703.                                   CDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD4               3                     3
  2704.                                   3     Octet 1     3     Octet 2       3   Class of    3        Meaning      3
  2705.                                   3Bits 8765  4321  3  Bits 8765  4321  3     Error     3                     3
  2706.                                   3                 3                   3               3                     3
  2707.                                   CDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDD3
  2708.  
  2709.                                                                                34
  2710.  
  2711.  
  2712.  
  2713.  
  2714.  
  2715.  
  2716.  
  2717.                                   3   1101  0000    3  Discarded PDU    3   Security    3    Security Option  3
  2718.                                   3                 3  Offset or Zero   3               3    Out-of-Range     3
  2719.                                   3                 3                   3               3                     3
  2720.                                   3   1101  1010    3    0000 0000      3   Security    3    Basic Portion    3 
  2721.                                   3                 3                   3               3    Missing          3 
  2722.                                   3                 3                   3               3                     3 
  2723.                                   3   1101  1101    3    0000 0000      3   Security    3    Extended Portion 3
  2724.                                   3                 3                   3               3    Missing          3
  2725.                                   3                 3                   3               3                     3
  2726.                                   3   1101  0010    3    0000 0000      3   Security    3    Communication    3
  2727.                                   3                 3                   3               3    Administratively 3
  2728.                                   3                 3                   3               3    Prohibited       3
  2729.                                   3                 3                   3               3                     3
  2730.                                   @DDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDY
  2731.                                            Table 6.1   Extended Values in the  Reason For Discard
  2732.                               Parameter
  2733.  
  2734.             6.2  SECURITY PARAMETER FORMAT
  2735.  
  2736.             IS 8473  defines the format  of the CLNP  security parameter.   This parameter
  2737.             consists of the three fields shown in Table 6.2.
  2738.              
  2739.                                                 Bits 8765  4321
  2740.                                   ZDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD?
  2741.                                   3  Octets      3                3
  2742.                                   3              3  1100  0101    3        Parameter Code
  2743.                                   3   N          3                3
  2744.                                   CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
  2745.                                   3              3                3
  2746.                                   3   N + 1      3  Len = M       3        Parameter Length
  2747.                                   3              3                3
  2748.                                   CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
  2749.                                   3   N + 2      3                3
  2750.                                   3              3                3        Parameter Value
  2751.                                   3   N + M + 1  3                3
  2752.                                   @DDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
  2753.  
  2754.                               Table 6.2  Security Parameter Format 
  2755.  
  2756.             6.2.1  Parameter Code
  2757.              
  2758.             IS 8473 assigns the value "1100 0101" to the Parameter Code field  to identify
  2759.             the parameter as the Security Option.
  2760.  
  2761.             6.2.2  Parameter Length
  2762.              
  2763.             This octet indicates the length, in octets, of the Parameter Value field. 
  2764.  
  2765.             6.2.3  Parameter Value
  2766.              
  2767.             The Parameter Value field  contains the security information. IS  8473 defines
  2768.             only the first octet of the Parameter Value field.  This section completes the
  2769.  
  2770.                                                   35
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.  
  2777.  
  2778.             definition of this  field. Table 6.3 illustrates  the format of the  Parameter
  2779.             Value field within the Security Parameter.                                 
  2780.  
  2781.  
  2782.                                                Bits 8765  4321                                           
  2783.                                   ZDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDD?                                      
  2784.                                   3  Octets    3                  3                                      
  2785.                                   3N           3    1100  0101    3   Parameter Code                     
  2786.                                   CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4                                        
  2787.                                   3            3                  3                                        
  2788.                                   3N+1         3  Len = B + E + 1 3   Parameter Length                 
  2789.                                   3            3                  3                                       
  2790.                                   CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
  2791.                                   3            3                  3                                      3 
  2792.                                   3N+2         3  XX00   0000     3   Security Format Code               3
  2793.                                   3            3                  3                                      3
  2794.                                   CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4                                      3
  2795.                                   3N+3         3                  3                                  Parameter
  2796.                                   3            3                  3   Basic Portion (Optional)         Value
  2797.                                   3N+B+2       3                  3                                      3
  2798.                                   CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4                                      3
  2799.                                   3N+B+3       3                  3                                      3
  2800.                                   3            3                  3   Extended Portion (Optional)        3
  2801.                                   3N+B+E+2     3                  3                                      3 
  2802.                                   @DDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
  2803.                                                                              
  2804.                               Table 6.3  Format - Parameter Value Field
  2805.  
  2806.  
  2807.  
  2808.  
  2809.  
  2810.  
  2811.  
  2812.  
  2813.  
  2814.  
  2815.  
  2816.  
  2817.  
  2818.  
  2819.  
  2820.  
  2821.  
  2822.  
  2823.  
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.                                                         36
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.             6.2.3.1  Security Format Code
  2840.              
  2841.             As described  in IS 8473, the  high order two bits  of the first  octet of the
  2842.             Parameter Value field specify the Security Format Code.  The standard reserves
  2843.             the remaining six bits and specifies that they must be zero. 
  2844.               
  2845.             6.2.3.2  Basic Portion
  2846.              
  2847.             The Basic Portion  of the Security  Option identifies the U.S.  classification
  2848.             level to which a PDU  is to be protected and the  authorities whose protection
  2849.             rules apply to that PDU.  This portion is optional and appears at most once in
  2850.             a PDU.   When the Basic  Portion appears in the  Security Option of  a PDU, it
  2851.             must  be  the first  portion  in the  Parameter  Value field  of  the Security
  2852.             Parameter.  Paragraph 6.3 defines the format of the Basic Portion. 
  2853.              
  2854.             6.2.3.3  Extended Portion 
  2855.              
  2856.             The Extended Portion permits additional security labelling information, beyond
  2857.             that present in the  Basic Portion, to be supplied  in a CLNP PDU to  meet the
  2858.             needs of registered authorities.  This portion is optional and appears at most
  2859.             once in  a PDU.    The Extended  Portion must  follow  the Basic  Portion,  if
  2860.             present, in the  Parameter Value  field of  the CLNP Security  Parameter.   In
  2861.             addition, if this portion is required  by an authority for a specific  system,
  2862.             it must  be specified explicitly in any Request  for Proposal for that system.
  2863.             Paragraph 6.4 defines the format of the Extended Portion. 
  2864.  
  2865.             6.3  BASIC PORTION OF THE SECURITY OPTION 
  2866.  
  2867.             The Basic Portion is used by the components of an internetwork to: 
  2868.  
  2869.                 A.    Transmit  from   source  to  destination,  in   a  network  standard
  2870.             representation,  the  common  security labels  required  by  computer security
  2871.             models.
  2872.                    
  2873.                 B.  Validate the PDU  as appropriate for transmission from the source  and
  2874.             delivery to the destination. 
  2875.                 C.   Ensure  that the  route taken  by the PDU is  protected to  the level
  2876.             required by all protection authorities indicated on the PDU. 
  2877.              
  2878.             Table 6.4 shows the format of the Basic Portion of the Security Option. 
  2879.  
  2880.                                                Bits 8765 4321
  2881.                                                     ZDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD?
  2882.                                                     3      Octets   3                   3
  2883.                                                     3   N           3     1000  0010    3     Basic Type Indicator
  2884.                                                     3               3                   3
  2885.                                                     CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4
  2886.                                                     3               3                   3
  2887.                                                     3   N+1         3     Len = I       3     Length of Basic Information
  2888.                                                     3               3                   3
  2889.                                                     CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4
  2890.                                                     3               3                   3
  2891.  
  2892.                                                                                         37
  2893.  
  2894.  
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900.                                                     3   N+2         3                   3
  2901.                                                     3               3                   3     Basic Information
  2902.                                                     3   N+I+1       3                   3
  2903.                                                     @DDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDY
  2904.                                                      
  2905.                                       Table 6.4  Format - Basic Portion
  2906.             6.3.1  Basic Type Indicator
  2907.              
  2908.             The value of this field identifies  this as the Basic Portion of the  Security
  2909.             Option. 
  2910.              
  2911.  
  2912.             6.3.2  Length of Basic Information 
  2913.              
  2914.             This length field, when present, indicates the length, in octets, of the Basic
  2915.             Information field.  The Basic Information field  is variable in length and has
  2916.             a minimum length of two octets. 
  2917.               
  2918.             6.3.3  Basic Information 
  2919.              
  2920.             The  Basic  Information  field   consists  of  two  subfields  as   Table  6.5
  2921.             illustrates. 
  2922.  
  2923.  
  2924.                                                   Bits 8765  4321
  2925.                                   ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
  2926.                                   3Octets       3                 3
  2927.                                   3 B           3   1000  0010    3  Basic Type Indicator
  2928.                                   3             3                 3
  2929.                                   CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
  2930.                                   3             3                 3
  2931.                                   3  B + 1      3   Len = F + 1   3  Length of Basic Information
  2932.                                   3             3                 3  (Minimum = 2 Octets)
  2933.                                   CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD 
  2934.                                   3             3                 3                                      3 
  2935.                                   3  B + 2      3                 3  Classification Level                3
  2936.                                   3             3                 3                                      3
  2937.                                   CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4                                   Basic    
  2938.                                   3             3                 3                                Information
  2939.                                   3B + 3        3                 3                                      3 
  2940.                                   3             3                 3   Protection Authority Flags         3
  2941.                                   3B + F + 2    3                 3                                      3
  2942.                                   @DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD  
  2943.                                             Table 6.5  Format - Basic Information Field 
  2944.              
  2945.             6.3.3.1  Classification Level
  2946.              
  2947.             The Classification  Level  field specifies  the U.S.  classification level  to
  2948.             which the PDU must be  protected.  The information in the PDU  must be treated
  2949.             at this level unless it is regraded in accordance under the procedures of  all
  2950.             the  authorities identified by  the Protection Authority Flags.   The field is
  2951.             one octet in length. Table 6.6 provides the encodings for this field. 
  2952.  
  2953.                                                   38
  2954.  
  2955.  
  2956.  
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.                       ZDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDD?
  2963.                       3    VALUE            3      LEVEL         3
  2964.                       3 Bits 8765 4321      3                    3
  2965.                       CDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDD4
  2966.                       3      0000 0001      3   RESERVED 4       3
  2967.                       3      0011 1101      3   TOP SECRET       3
  2968.                       3      0101 1010      3   SECRET           3
  2969.                       3      1001 0110      3   CONFIDENTIAL     3
  2970.                       3      0110 0110      3   RESERVED 3       3
  2971.                       3      1100 1100      3   RESERVED 2       3
  2972.                       3      1010 1011      3   UNCLASSIFIED     3
  2973.                       3      1111 0001      3   RESERVED 1       3
  2974.                       @DDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDY
  2975.                                             Table 6.6  Classification Levels 
  2976.  
  2977.             6.3.3.2  Protection Authority Flags 
  2978.              
  2979.             The Protection Authority  Flags field indicates the National Access Program(s)
  2980.             or Special Access Program(s) whose rules  apply to the protection of the  PDU.
  2981.             Its  field length  and source  flags  are described  below.   To  maintain the
  2982.             architectural  consistency  and  interoperability  of  DoD  common  user  data
  2983.             networks, users  of these networks  should submit requirements  for additional
  2984.             Protection Authority  Flags to  DCA DISDB,  Washington, D.  C. 20305-2000  for
  2985.             review and approval.
  2986.  
  2987.                 A.  Field Length:  The Protection Authority Flags field is variable  in
  2988.                 length.  The  low order bit (Bit  1) of an octet  is encoded as "0"  if
  2989.                 the  octet is the  final octet in  the field.   If there are additional
  2990.                 octets,  then the low  order bit is  encoded as "1".   Currently, there
  2991.                 are  less  than  eight  authorities.   Therefore,  only  one  octet  is
  2992.                 required and the low order bit of this octet is encoded as "0".
  2993.              
  2994.                 B.  Source  Flags:  Bits  2 through 8  in each octet  are flags.   Each
  2995.                 flag is associated with  an authority as indicated  in Table 6.7.   The
  2996.                 bit corresponding to an authority is "1" if the  PDU is to be protected
  2997.                 in accordance with the rules of that authority. 
  2998.                                
  2999.                            ZDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD? 
  3000.                            3   Bit     3                  3                                                  3
  3001.                            3 Number    3   Authority      3     Point of Contact                             3
  3002.                            CDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4 
  3003.                            3           3                  3                                                  3
  3004.                            3   8       3GENSER            3  Designated Approving Authority                  3
  3005.                            3           3                  3  per DoD 5200.28                                 3
  3006.                            3           3                  3                                                  3
  3007.                            3   7       3SIOP-ESI          3  Department of Defense                           3
  3008.                            3           3                  3  Organization of the                             3
  3009.                            3           3                  3  Joint Chiefs of Staff                           3
  3010.                            3           3                  3  Attn: J6T                                       3
  3011.                            3           3                  3  Washington, D.C.                                3
  3012.                            3           3                  3                                                  3
  3013.  
  3014.                                                                            39
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020.  
  3021.  
  3022.                            3   6       3 SCI              3  Director of Central Intelligence                3
  3023.                            3           3                  3  Attn: Chairman, Information Handling Committee  3
  3024.                            3           3                  3  Intelligence Community Staff                    3
  3025.                            3           3                  3  Washington, D. C. 20505                         3
  3026.                            3           3                  3                                                  3
  3027.                            3   5       3 NSA              3  National Security Agency                        3
  3028.                            3           3                  3  9800 Savage Road                                3
  3029.                            3           3                  3  Attn: TO3                                       3
  3030.                            3           3                  3  Ft. Meade, MD 20755-6000                        3
  3031.                            3           3                  3                                                  3
  3032.                            3    4      3 DOE              3  Department of Energy                            3
  3033.                            3           3                  3  Attn: DP343.2                                   3
  3034.                            3           3                  3  Washington, D.C. 20545                          3
  3035.                            3           3                  3                                                  3
  3036.                            3  3 , 2    3 Unassigned       3                                                  3
  3037.                            3           3                  3                                                  3
  3038.                            3    1      3 Extension Bit    3  Presently always "O"                            3
  3039.                            @DDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
  3040.                              Table 6.7  Protection Authority Bit Assignments                   
  3041.                   
  3042.  
  3043.             6.4  EXTENDED PORTION OF THE SECURITY OPTION 
  3044.              
  3045.             Table 6.8 illustrates  the format for the  Extended Portion.  To  maintain the
  3046.             architectural consistency of  DoD common user  data networks, and to  maximize
  3047.             interoperability, users of  these networks should  submit their plans for  the
  3048.             use of  the Extended Portion of the Security  Option to DCA DISDB, Washington,
  3049.             D.C. 20305-2000 for review and approval.  Once approved, DCA DISDB will assign
  3050.             Additional Security Information Format Codes to the requesting activities. 
  3051.  
  3052.  
  3053.  
  3054.  
  3055.  
  3056.  
  3057.  
  3058.  
  3059.  
  3060.  
  3061.  
  3062.  
  3063.  
  3064.  
  3065.  
  3066.  
  3067.  
  3068.  
  3069.  
  3070.  
  3071.  
  3072.  
  3073.  
  3074.  
  3075.                                                   40
  3076.  
  3077.  
  3078.  
  3079.  
  3080.  
  3081.  
  3082.  
  3083.                                                  Bits 8765  4321
  3084.                                    ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
  3085.                                    3    Octets   3                 3
  3086.                                    3  N          3    1000  0101   3  Extended Type Indicator
  3087.                                    CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
  3088.                                    3             3                 3
  3089.                                    3   N+1       3   Len = I       3  Length of Extended Information
  3090.                                    3             3                 3
  3091.                                    CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
  3092.                                    3   N+2       3                 3
  3093.                                    3             3                 3  Extended Information
  3094.                                    3   N+I+1     3                 3
  3095.                                    @DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDY
  3096.                                         Table 6.8  Format - Extended Portion 
  3097.  
  3098.             6.4.1  Extended Type Indicator
  3099.  
  3100.             The value  of  this field  identifies  this as  the  Extended Portion  of  the
  3101.             Security Option. 
  3102.              
  3103.             6.4.2  Length of Extended Information 
  3104.              
  3105.             This length field indicates the length, in octets, of the Extended Information
  3106.             field.  The  Extended Information field is  variable in length with  a minimum
  3107.             length of two octets. 
  3108.              
  3109.             6.4.3  Extended Information
  3110.              
  3111.             The  Extended  Information field  consists  of  three subfields  as  Table 6.9
  3112.             illustrates.  These  three fields form a  sequence.  This sequence  may appear
  3113.             multiple times, forming a set, within the Extended Information field. 
  3114.  
  3115.  
  3116.  
  3117.  
  3118.  
  3119.  
  3120.  
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126.  
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132.  
  3133.  
  3134.  
  3135.  
  3136.                                                   41
  3137.  
  3138.  
  3139.  
  3140.  
  3141.  
  3142.  
  3143.  
  3144.              
  3145.                                        Bits 8765  4321
  3146.                          ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
  3147.                          3   Octets                       3
  3148.                          3  E                1000  0101   3  Extended Type Indicator
  3149.                          CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
  3150.                          3   E+1            Len =  (B -  A) +  1   3   Length of  Extended
  3151.             Information
  3152.                          3                                3    (Minimum = 2 Octets)
  3153.                                                                                    
  3154.             CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
  3155.             DDDDDDDDD?
  3156.                          3                                 3                              
  3157.                                  3
  3158.                    A       3  E+2                                  3   Additional Security
  3159.             Information Format Code        3
  3160.                          3                                 3                              
  3161.                                  3
  3162.                          CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                               
  3163.                                  3
  3164.                          3                                 3                              
  3165.                                  3
  3166.                          3  E+3       Len = I             3  Length of Additional Security
  3167.             Information          3
  3168.                          3                                 3                              
  3169.                                  3
  3170.                          CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                               
  3171.                                  3
  3172.                          3                                 3                              
  3173.                                  3
  3174.                          3  E+4                           3                               
  3175.                                  3
  3176.                          3                                         3   Additional Security
  3177.             Information                    3
  3178.                          3  E+I+3                         3   (Zero or more octets)       
  3179.                                  3
  3180.                          @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY                               
  3181.                                  3
  3182.                          .                                 .                              
  3183.                                  3
  3184.                          .     (Additional Sequences      .                               
  3185.                               Extended
  3186.                          .    of the above three fields)  .                               
  3187.                             Information
  3188.                          .                                .                               
  3189.                                  3
  3190.                          ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?                              
  3191.                                  3
  3192.                          3   E+N                                     3 Additional Security
  3193.             Information Format Code        3
  3194.                          CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                              
  3195.                                  3
  3196.  
  3197.                                                   42
  3198.  
  3199.  
  3200.  
  3201.  
  3202.  
  3203.  
  3204.  
  3205.                          3                                 3                              
  3206.                                  3
  3207.                          3 E+N+1       Len = J             3 Length of Additional Security
  3208.             Information          3
  3209.                          3                                 3                              
  3210.                                  3
  3211.                          CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4                              
  3212.                                  3
  3213.                          3 E+N+2                           3                              
  3214.                                  3
  3215.                          3                                           3 Additional Security
  3216.             Information                    3
  3217.                   B       3 E+N+J+1                         3   (Zero or more octets)     
  3218.                                  3
  3219.                                                                                    
  3220.             @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
  3221.             DDDDDDDDDY
  3222.                                     Table 6.9  Format - Extended Information Field
  3223.              
  3224.             6.4.3.1  Additional Security Information Format Code 
  3225.                   
  3226.             The value of the Additional Security  Information Format Code corresponds to a
  3227.             particular format and meaning  for a specific Additional Security  Information
  3228.             field.   Each format  code is assigned  to a  specific controlling  activity. 
  3229.             Once assigned, this  activity becomes the authority for  the definition of the
  3230.             remainder of  the Additional Security  Information identified  by that  format
  3231.             code.  A single  controlling activity may be  responsible for multiple  format
  3232.             codes.  However, a  particular format code may  appear at most once in  a PDU.
  3233.             For  each  Additional  Security  Information   Format  Code  an  authority  is
  3234.             responsible  for,  that   authority  will  provide  sufficient   criteria  for
  3235.             determining whether a CLNP PDU marked with  its Format Code should be accepted
  3236.             or rejected.  Whenever possible, this criteria will be Unclassified.   
  3237.              
  3238.             Note: The bit  assignments for  the Protection  Authority flags  of the  Basic
  3239.             Portion  of  the  Security Option  have  no  relationship  to the  "Additional
  3240.             Security Information Format Code" of this portion. 
  3241.              
  3242.             6.4.3.2  Length of Additional Security Information 
  3243.              
  3244.             This  field  provides  the length,  in  octets,  of  the "Additional  Security
  3245.             Information" field immediately following. 
  3246.  
  3247.             6.4.3.3  Additional Security Information 
  3248.              
  3249.             The Additional  Security Information  field contains  the additional  security
  3250.             relevant information specified  by the authority identified by the "Additional
  3251.             Security Information Format Code."  The format, length, content, and semantics
  3252.             of this field  are determined by that  authority.  The minimum length  of this
  3253.             field 
  3254.             is zero. 
  3255.              
  3256.             6.5  USAGE GUIDELINES 
  3257.  
  3258.                                                   43
  3259.  
  3260.  
  3261.  
  3262.  
  3263.  
  3264.  
  3265.  
  3266.              
  3267.             A PDU is "within the range" if 
  3268.              
  3269.                            MIN-LEVEL <= PDU-LEVEL <= MAX-LEVEL 
  3270.              
  3271.                   where  MIN-LEVEL and  MAX-LEVEL  are the  minimum  and maximum  security
  3272.             levels, respectively, that the system  is accredited for.  The term  PDU-LEVEL
  3273.             refers  to the  security level of  the PDU.   In  this context,  the "security
  3274.             level" may involve the combination of three factors:
  3275.  
  3276.                 1)  classification level
  3277.                 2)  protection authorities
  3278.                 3)  additional security  labelling information as required  and defined by
  3279.             the responsible activity.
  3280.  
  3281.             The authorities responsible for accrediting a  system or collection of systems
  3282.             are also responsible for determining whether and how these factors interact to
  3283.             form a security level or security range.  A PDU should be accepted for further
  3284.             processing only if it is within range.  Otherwise, the  Out-of-Range procedure
  3285.             described in Paragraph 6.6 should be followed.
  3286.              
  3287.             6.5.1  Basic Portion of the Security Option 
  3288.              
  3289.             Use of  the information contained in the Basic  Portion of the Security Option
  3290.             requires that an end system be aware of: 
  3291.              
  3292.                 A.   the classification  level, or  levels, at  which it  is permitted  to
  3293.             operate, and 
  3294.              
  3295.                 B.  the protection authorities responsible for its accreditation. 
  3296.              
  3297.             Representation of this configuration information is implementation dependent.
  3298.  
  3299.             6.5.2  Extended Portion of the Security Option 
  3300.              
  3301.             Use of  the Extended  Portion of  the Security  Option requires  that the  end
  3302.             system  configuration accurately reflects  the accredited  security parameters
  3303.             associated with communication  via each network interface.   Representation of
  3304.             the security parameters  and their binding  to specific network interfaces  is
  3305.             implementation dependent.
  3306.  
  3307.             6.6  OUT-OF-RANGE PROCEDURE 
  3308.              
  3309.             If the Out-Of-Range condition was triggered by: 
  3310.  
  3311.                 A.   A  required,  but missing,  Security Option  or Basic  or Extended
  3312.                 Portion of  a Security Option,  then the PDU  should be discarded.   In
  3313.                 addition, a CLNP  Error Report or other form of  reply is not permitted
  3314.                 in this case.  However,  a local security policy may permit data  to be
  3315.                 delivered  or a CLNP Error Report PDU  to be processed provided a reply
  3316.                 is not sent.
  3317.  
  3318.  
  3319.                                                   44
  3320.  
  3321.  
  3322.  
  3323.  
  3324.  
  3325.  
  3326.  
  3327.                 B.   A PDU whose security level  is less than the  end system's minimum
  3328.                 security level, then the  PDU should be discarded.  In addition, a CLNP
  3329.                 Error Report  or other form  of reply  is not  permitted in this  case.
  3330.                 However,  local security policy  may permit  data to be  delivered or a
  3331.                 CLNP Error Report PDU to be processed provided a reply is not sent. 
  3332.                    
  3333.                 C.    A PDU  whose  security level  is  greater than  the  end system's
  3334.                 maximum security level, then: 
  3335.  
  3336.                   1.   If a  CLNP Error Report  PDU triggered the  Out-of-Range condition,
  3337.                 then no reply is permitted and the PDU  should be discarded.  A CLNP Error
  3338.                 Report PDU must not be sent in this case.
  3339.                    
  3340.                   2.  Otherwise, discard the  PDU and send a CLNP Error Report  PDU to the
  3341.                 originating CLNP  entity.   The  first  octet of  the Reason  for  Discard
  3342.                 parameter is  set as  specified in Table  6.1.   The second  octet of  the
  3343.                 Reason  for Discard parameter identifies  the Out-of-Range  portion of the
  3344.                 Security Option.   It  should point  to the  first octet  (i.e., the  type
  3345.                 indicator) of the Out-of-Range  portion.  Alternatively, the second  octet
  3346.                 can be  set to  zero. The response  is sent at the  maximum classification
  3347.                 level of the end system which received the PDU.   The protection authority
  3348.                 flags  are set  to  be the  intersection of  those for  which the  host is
  3349.                 accredited and those present in the PDU which triggered this response.
  3350.  
  3351.                   Example:  PDU = "Secret, GENSER"
  3352.                         End System Level = "Unclassified, GENSER".
  3353.                         Reply  = "Unclassified, GENSER".
  3354.  
  3355.             These  are  the   least  restrictive  actions  permitted   by  this  protocol.
  3356.             Individual end systems,  system administrators, or protection  authorities may
  3357.             impose  more stringent restrictions on responses and in some instances may not
  3358.             permit any response at  all to a PDU which is outside  the accredited security
  3359.             range of an end system.
  3360.  
  3361.             6.7  TRUSTED INTERMEDIARY PROCEDURE 
  3362.              
  3363.             Certain devices  in an internetwork may act as intermediaries to validate that
  3364.             communications between two end  systems is authorized.  This decision is based
  3365.             on  a combination of knowledge of  the end systems and  the values in the CLNP
  3366.             Security Option.   [The  Blacker Front  End (BFE)  is  one example  of such  a
  3367.             trusted device.]  These  devices may receive CLNP PDUs which  are in range for
  3368.             the  intermediate device, but are  either not within  the accredited range for
  3369.             the source or the destination.  In the former case, the PDU  should be treated
  3370.             as described  in Paragraph 6.6.  In  the latter case, a CLNP  Error Report PDU
  3371.             should be sent to the originating CLNP  entity.  The first octet of the Reason
  3372.             for Discard parameter should be set to 1101 0010.   This code indicates to the
  3373.             originating  CLNP   entity  that   communication  with   the  end   system  is
  3374.             administratively prohibited (refer to Table  6.1).  The security range  of the
  3375.             interface  on  which the  reply will  be  sent determines  whether a  reply is
  3376.             allowed and at what security level it should be sent.
  3377.  
  3378.  
  3379.  
  3380.                                                   45
  3381.  
  3382.  
  3383.  
  3384.  
  3385.  
  3386.  
  3387.  
  3388.                                               REFERENCES
  3389.  
  3390.  
  3391.             National Institute of Standards and Technology
  3392.  
  3393.                   1.  NIST  Special Publication 500-177, Stable  Implementation Agreements
  3394.             for Open Systems Interconnection Protocols,  Version 3.  This document can  be
  3395.             purchased from National Technical Information Service (NTIS), U. S. Department
  3396.             of Commerce,  5285 Port  Royal Road,  Springfield,  VA 22161.   For  telephone
  3397.             orders call: (703)  487-4650.  This  document may also  be purchased from  the
  3398.             IEEE Computer Society, Order Department, phone: 1-800-272-6657.
  3399.  
  3400.                   2.   FIPS l07, Local  Area Networks:   Baseband  Carrier Sense  Multiple
  3401.             Access   with   Collision   Detection  Access   Method   and   Physical  Layer
  3402.             Specifications and  Link Layer  Protocol, NTIS,  U.S. Department  of Commerce,
  3403.             5285 Port Royal Road,  Springfield, VA  22l6l. 
  3404.                
  3405.                   3.  FIPS l00, Interface  Between Data Terminal Equipment (DTE) and  Data
  3406.             Circuit-Terminating Equipment  (DCE) For  Operation With  Packet-Switched Data
  3407.             Communications Networks,  NTIS, U.S. Department  of Commerce, 5285  Port Royal
  3408.             Road, Springfield, VA 22l6l. 
  3409.                
  3410.                   4.   Implementation Agreements Among  Participants of OSINET,  NBSIR 89-
  3411.             4158, National Institute of Standards and Technology.
  3412.  
  3413.                   5.  Military Supplement to ISO Transport Protocol, National Institute of
  3414.             Standards and Technology,  National Computer Systems  Laboratory, ICST/SNA-85-
  3415.             17, 1985.
  3416.  
  3417.                   6.  Implementation Guide for ISO Transport  Protocol, National Institute
  3418.             of Standards and  Technology, National Computer Systems  Laboratory, ICST/SNA-
  3419.             85-18, 1985.
  3420.  
  3421.                   7.     NIST  Special   Publication  500-163   Government  Open   Systems
  3422.             Interconnection  User's  Guide.   This  document  can  be  purchased from  the
  3423.             National Technical Information  Service (NTIS), U. S. Department  of Commerce,
  3424.             5285 Port Royal Road, Springfield, VA 22161.  For telephone orders call (7023)
  3425.             487-4650.  The NTIS order number is PB90-111212. 
  3426.  
  3427.                   8.    GOSIP  Conformance and  Interoperation  Testing  and Registration,
  3428.             NCSL/SNA 90-2, 1990.
  3429.  
  3430.                   9.    NIST   Special  Publication  500-182,  Message   Handling  Systems
  3431.             Implementation  Evaluation  Guidelines.   See  [NIST  7]  for   NTIS  ordering
  3432.             information.
  3433.  
  3434.             National Communications System
  3435.  
  3436.             Federal Standard FED-STD 1041, Interface Between Data Terminal Equipment (DTE)
  3437.             and  Data  Circuit-Terminating  Equipment  (DCE)  For Operation  With  Packet-
  3438.             Switched Data Communications Networks, National Communications System.
  3439.  
  3440.  
  3441.                                                   46
  3442.  
  3443.  
  3444.  
  3445.  
  3446.  
  3447.  
  3448.  
  3449.             Institute of Electrical and Electronic Engineers, Inc.
  3450.                  
  3451.             Binary Floating Point  Arithmetic (ANS1 Approved),  IEEE 754, March 21,  1985,
  3452.             Institute of Electrical and Electronics Engineers.
  3453.                
  3454.             The above document may be obtained from: IEEE Standards Office, 345  East 47th
  3455.             Street, New York, N.Y.  l00l7. 
  3456.  
  3457.             Electronic Industries Association
  3458.  
  3459.             Interface between  Data Terminal  Equipment and  Data Communication  Equipment
  3460.             Employing Serial Binary Data Interchange, EIA-232C.
  3461.             American National Standards Institute
  3462.  
  3463.                 1.  Integrated  Services Digital Network - Basic Access Interface  for Use
  3464.             on  Metallic  Loops for  Application on  the  Network Side  of the  NT-Layer 1
  3465.             Specification, ANS T1.601-1988.
  3466.  
  3467.                 2.  Integrated Services Digital Network  - Basic Access Interface at S and
  3468.             T Reference Points - Layer 1 Specification, ANS T1.605-1988.
  3469.                
  3470.                 3.   Carrier to  Customer Installation -  DS1 Metallic  Interface, ANS T1.
  3471.             403-1989.
  3472.  
  3473.             International Organization for Standardization
  3474.  
  3475.                 1.  Information Processing Systems  - Open Systems Interconnection - Basic
  3476.             Reference Model, Ref. No. ISO 7498-1984(E).
  3477.                
  3478.                 2.  Information Processing Systems - Data Communications - Use  of X.25 to
  3479.             provide the OSI Connection Mode Network Service, IS 8878.
  3480.                
  3481.                 3.    Information Processing  Systems  -  Open  Systems  Interconnection -
  3482.             Network Service Definition, IS 8348.
  3483.  
  3484.                 4.    Information  Processing  Systems -  Open  Systems Interconnection  -
  3485.             Addendum  to  the  Network  Service  Definition Covering  Connectionless  Data
  3486.             Transmission, ISO 8348 Addendum 1.
  3487.                
  3488.                 5.    Information  Processing Systems  -  Open Systems  Interconnection  -
  3489.             Addendum to  the Network Service Definition Covering Network Layer Addressing,
  3490.             ISO 8348 Addendum 2. 
  3491.  
  3492.                 6.    Information Processing  Systems  - Open  Systems  Interconnection  -
  3493.             Internal Organization of the Network Layer, DIS 8648, N3985, Feb., 1986. 
  3494.                
  3495.                 7.    Information Processing  Systems  -  Open  Systems  Interconnection -
  3496.             Protocol  for Providing the  Connectionless Network  Service, IS  8473, N3998,
  3497.             March, 1986.       
  3498.  
  3499.                 8.  Information Processing  Systems - Open Systems  Interconnection - Data
  3500.             Communication - X.25  Packet Level Protocol  for Data Terminal Equipment,  ISO
  3501.  
  3502.                                                   47
  3503.  
  3504.  
  3505.  
  3506.  
  3507.  
  3508.  
  3509.  
  3510.             8208.    
  3511.  
  3512.                 9.  7-bit Coded Character  Set for Information Processing Interchange, ISO
  3513.             646, l973. 
  3514.                
  3515.                 10.     Information   Interchange  --   Representation   of   Local   Time
  3516.             Differentials, ISO 3307, l975. 
  3517.  
  3518.                 11.   Information  Processing  Systems -  Open Systems  Interconnection  -
  3519.             Working Draft -  End System to  Intermediate System Routing Exchange  Protocol
  3520.             for use in Conjunction with ISO 8473.
  3521.                
  3522.                 12.   Information  Processing Systems  - Open  Systems  Interconnection  -
  3523.             Transport Service Definition, ISO 8072, l984. 
  3524.  
  3525.                 13.   Information Processing  Systems  -  Open Systems  Interconnection  -
  3526.             Transport Protocol Specification, ISO 8073, l984. 
  3527.                
  3528.                 14.    Information  Processing Systems  -  Open Systems  Interconnection -
  3529.             Session Service Definition, ISO 8326, l987(E). 
  3530.  
  3531.                 15.   Information  Processing Systems  - Open  Systems  Interconnection  -
  3532.             Session Protocol Specification, ISO 8327, l987(E). 
  3533.                
  3534.                 16.  Information Processing Systems  - Open Systems Interconnection - File
  3535.             Transfer, Access and Management Part 1:  General Introduction, ISO 8571-1. 
  3536.  
  3537.                 17.  Information Processing Systems  - Open Systems Interconnection - File
  3538.             Transfer, Access and Management Part 2:  The Virtual Filestore Definition, ISO
  3539.             8571-2.
  3540.                
  3541.                 18.  Information Processing Systems  - Open Systems Interconnection - File
  3542.             Transfer, Access and Management Part 3:   File Service Definition, ISO 8571-3.
  3543.  
  3544.  
  3545.                 19.  Information Processing Systems  - Open Systems Interconnection - File
  3546.             Transfer, Access  and Management  Part 4:   File  Protocol Specification,  ISO
  3547.             8571-4.
  3548.                
  3549.                 20.   Information  Processing Systems  - Open  Systems  Interconnection  -
  3550.             Connection-Oriented Presentation Service Definition, ISO 8822.
  3551.                
  3552.                 21.   Information Processing  Systems  -  Open Systems  Interconnection  -
  3553.             Connection-Oriented Presentation Protocol Specification, ISO 8823. 
  3554.  
  3555.                 22.    Information  Processing Systems  -  Open Systems  Interconnection -
  3556.             Service  Definition  for  Association  Control  Service  Element   -  Part  2:
  3557.             Association Control, ISO 8649.
  3558.                
  3559.                 23.    Information Processing  Systems  - Open  Systems Interconnection  -
  3560.             Protocol  Specification for Association  Control Service  Element: Association
  3561.             Control,  ISO 8650.
  3562.  
  3563.                                                   48
  3564.  
  3565.  
  3566.  
  3567.  
  3568.  
  3569.  
  3570.  
  3571.                
  3572.                 24.   Information  Processing  Systems  - Open  Systems  Interconnection -
  3573.             Specification of Abstract Syntax Notation One (ASN.1), ISO 8824.
  3574.  
  3575.                 25.  Information Processing Systems - Open Systems Interconnection - 
  3576.             Specification  of  Basic  Encoding  Rules for  Abstract  Syntax  Notation  One
  3577.             (ASN.1), ISO 8825.
  3578.  
  3579.                 26.   Information Processing  Systems - Data  Communications -  High-Level
  3580.             Data Link Control  Procedures -  Description of the  X.25 LAPB-compatible  DTE
  3581.             Data Link Procedures, ISO 7776.
  3582.  
  3583.                 27.  Information  Processing Systems -  Data Interchange -  Structures for
  3584.             the Identification of Organizations, ISO 6523, 1984.
  3585.               
  3586.                 28.    Information Processing  Systems  - Local  Area  Networks -  Part 2:
  3587.                 Logical 
  3588.             Link Control, DIS 8802/2.
  3589.  
  3590.                 29.    Information Processing  Systems  - Local  Area Networks  -  Part 3:
  3591.             Carrier Sense Multiple Access With Collision Detection, ISO 8802/3
  3592.  
  3593.                 30.  Information Processing Systems - Local Area Networks - Part 4: Token-
  3594.             passing Bus Success Method and Physical Layer Specifications, ISO 8802/4.
  3595.  
  3596.                 3l.   Information Processing  Systems - Local Area Networks  Part 5: Token
  3597.             Ring Access Method and Physical Layer Specifications, ISO 8802/5.
  3598.  
  3599.                 32.   Information  Processing  Systems  - Open  Systems  Interconnection -
  3600.             Virtual Terminal Services - Basic Class, ISO 9040.
  3601.  
  3602.                 33.    Information Processing  Systems  - Open  Systems Interconnection  -
  3603.             Virtual Terminal Protocol - Basic Class, ISO 9041.
  3604.  
  3605.                 34.   Information  Processing  Systems  -  Open  Systems  Interconnection.
  3606.             Virtual Terminal Service, Basic Class, ISO 9040, Addendum 1, 1988.
  3607.  
  3608.                 35.   Information  Processing  Systems  -  Open  Systems  Interconnection,
  3609.             Virtual Terminal Protocol, Basic Class, ISO 9041, Addendum 1, 1988.
  3610.  
  3611.                 36.   Information Processing  -  Text and  Office  Systems-Office-Document
  3612.             Architecture (ODA) and Interchange  Format - Part 1: Introduction  and General
  3613.             Principles, ISO 8613-1, 1988.
  3614.  
  3615.                 37.   Information Processing  -  Text and  Office  Systems-Office-Document
  3616.             Architecture (ODA) and  Interchange Format -  Part 2: Document Structures  ISO
  3617.             8613-2, 1988.
  3618.  
  3619.                 38.   Information Processing  -  Text and  Office  Systems-Office-Document
  3620.             Architecture (ODA)  and Interchange  Format -  Part 4:  Document Profile,  ISO
  3621.             8613-4, 1988.
  3622.  
  3623.  
  3624.                                                   49
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.                 39.   Information Processing  -  Text and  Office  Systems-Office-Document
  3633.             Architecture  (ODA)  and   Interchange  Format  -  Part   5:  Office  Document
  3634.             Interchange Format (ODIF), ISO 8613-5, 1988.
  3635.  
  3636.                 40.   Information Processing  -  Text and  Office  Systems-Office-Document
  3637.             Architecture  (ODA)  and  Interchange  Format  -  Part  6:  Character  Content
  3638.             Architectures, ISO 8613-6, 1988.
  3639.  
  3640.                 41.   Information Processing  -  Text and  Office  Systems-Office-Document
  3641.             Architecture (ODA) and  Interchange Format -  Part 7: Raster Graphics  Content
  3642.             Architectures, ISO 8613-7, 1988.
  3643.  
  3644.                 42.   Information Processing  -  Text and  Office  Systems-Office-Document
  3645.             Architecture (ODA) and Interchange Format - Part 8: Geometric Graphics Content
  3646.             Architectures, ISO 8613-8, 1988.
  3647.  
  3648.                 43.    Information Processing  Systems -  Protocol  Identification  in the
  3649.             Network Layer, DTR 9577.
  3650.  
  3651.                 44.  Information  Processing Systems -  End System to  Intermediate System
  3652.             Routing Exchange Protocol for use with ISO 8473, IS 9542.
  3653.  
  3654.                 45.  Information Processing  Systems - Data Communications  - Provision of
  3655.             the OSI  Connection-mode Network  Service, by  Packet Mode  Terminal Equipment
  3656.             connected to an Integrated Services Digital Network (ISDN), DIS 9574.
  3657.  
  3658.                 46.    Information  Processing  Systems  -  Transport  Service  Definition
  3659.             covering Connectionless Mode Transmission, ISO 8072/ADD.
  3660.  
  3661.                 47.    Information  Processing  Systems  -   Protocol  for  Providing  the
  3662.             Connectionless Mode Transport Service, ISO 8602.
  3663.  
  3664.                 48.  Information  Processing Systems -  Telecommunications and information
  3665.             exchange between systems - OSI Routing Framework, ISO/TR 9575.
  3666.  
  3667.                 49.    Information Processing  Systems Telecommunications  and information
  3668.             exchange between systems  - Intermediate systems to Intermediate system Intra-
  3669.             Domain routing exchange protocol  for use in conjunction with the protocol for
  3670.             providing the Connectionless mode Network Service ISO/IEC JTC1/SC6 DP 10589.
  3671.  
  3672.             The above documents may be obtained from: 
  3673.                
  3674.                               ANSI Sales Department 
  3675.                               1430 Broadway
  3676.                               New York, NY 10018
  3677.                               (212) 642-4900
  3678.  
  3679.             International Telephone and Telegraph Consultative Committee
  3680.                   
  3681.                   1.    CCITT Recommendation  X.25-1984,  Interface Between  Data Terminal
  3682.             Equipment (DTE)  and Data  Circuit-Terminating Equipment  (DCE) for  Terminals
  3683.             Operating in the Packet Mode on Public Data Networks. 
  3684.  
  3685.                                                   50
  3686.  
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692.  
  3693.                
  3694.                   2.   CCITT  Recommendation  X.400, (Red  Book,  1984), Message  Handling
  3695.             Systems: System Model-Service Elements. 
  3696.                
  3697.                   3.   CCITT  Recommendation  X.40l, (Red  Book,  1984), Message  Handling
  3698.             Systems: Basic Service Elements and Optional User Facilities. 
  3699.                
  3700.                   4.   CCITT  Recommendation  X.408, (Red  Book,  1984), Message  Handling
  3701.             Systems: Encoded Information Type Conversion Rules. 
  3702.                
  3703.                   5.   CCITT  Recommendation  X.409, (Red  Book,  1984), Message  Handling
  3704.             Systems: Presentation Transfer Syntax and Notation. 
  3705.  
  3706.                   6.   CCITT  Recommendation  X.4l0, (Red  Book,  1984), Message  Handling
  3707.             Systems: Remote Operations and Reliable Transfer Server. 
  3708.  
  3709.                   7.   CCITT  Recommendation  X.4ll, (Red  Book,  1984), Message  Handling
  3710.             Systems: Message Transfer Layer. 
  3711.  
  3712.                   8.   CCITT  Recommendation  X.420, (Red  Book,  1984), Message  Handling
  3713.             Systems: Interpersonal Messaging User Agent Layer. 
  3714.                
  3715.                   9.   CCITT  Recommendation  X.430, (Red  Book,  1984), Message  Handling
  3716.             Systems: Access Protocol for Teletex Terminals. 
  3717.  
  3718.                   10.   CCITT Recommendation X.214,  (Red Book,  1984), Transport  Service
  3719.             Definition for Open Systems Interconnection for CCITT Applications. 
  3720.                
  3721.                   11.   CCITT Recommendation X.224,  (Red Book, 1984),  Transport Protocol
  3722.             Specification for Open Systems Interconnection for CCITT Applications. 
  3723.                
  3724.                   12.    CCITT  Recommendation X.215  (Red  Book,  1984),  Session Service
  3725.             Definition for Open Systems Interconnection for CCITT Applications. 
  3726.                
  3727.                   13.   CCITT  Recommendation  X.225 (Red  Book,  1984), Session  Protocol
  3728.             Specification for Open Systems Interconnection for CCITT Applications. 
  3729.                
  3730.                   14.  CCITT Recommendation X.400 - Series Implementor's Guide (Version 6,
  3731.             November 1987). 
  3732.                
  3733.                   15.    CCITT  Recommendation  X.121   (Red  Book,  1985),  International
  3734.             Numbering Plan for Public Data Networks.
  3735.  
  3736.                   16.  CCITT Recommendation V.35 - Data Transmission at 48 kilobits/second
  3737.             using 60-108 kHz group band circuits.
  3738.  
  3739.                   17.    CCITT  Recommendation  T.410  (Blue  Book,  1988)  Open  Document
  3740.             Architecture (ODA) and Interchange Format - Overview
  3741.  
  3742.                   18.    CCITT  Recommendation  T.411  (Blue  Book,  1988)  Open  Document
  3743.             Architecture  (ODA)  and   Interchange  Format  -  Introduction   and  General
  3744.             Principles
  3745.  
  3746.                                                   51
  3747.  
  3748.  
  3749.  
  3750.  
  3751.  
  3752.  
  3753.  
  3754.  
  3755.                   19.    CCITT  Recommendation  T.412  (Blue  Book,  1988)  Open  Document
  3756.             Architecture (ODA) and Interchange Format - Document Structures
  3757.  
  3758.                   20.    CCITT  Recommendation  T.414  (Blue  Book,  1988)  Open  Document
  3759.             Architecture (ODA) and Interchange Format - Document Profile
  3760.  
  3761.                   21.    CCITT  Recommendation  T.415  (Blue  Book,  1988)  Open  Document
  3762.             Architecture (ODA) and Interchange Format - Document Interchange Format (ODIF)
  3763.  
  3764.                   22.    CCITT  Recommendation  T.416  (Blue  Book,  1988)  Open  Document
  3765.             Architecture (ODA) and Interchange Format - Character Content Architectures
  3766.  
  3767.                   23.    CCITT  Recommendation  T.417  (Blue  Book,  1988)  Open  Document
  3768.             Architecture  (ODA)  and   Interchange  Format   -  Raster  Graphics   Content
  3769.             Architectures.
  3770.  
  3771.                   24.    CCITT  Recommendation  T.418  (Blue  Book,  1988)  Open  Document
  3772.             Architecture  (ODA)  and  Interchange  Format  -  Geometric  Graphics  Content
  3773.             Architectures.
  3774.  
  3775.                   25.  CCITT  Recommendation Q.921  (I.441) (Blue Book,  1988) ISDN  User-
  3776.             Network Interface Data Link Layer Specification.
  3777.  
  3778.                   26.  CCITT  Recommendation Q.931  (I.451) (Blue Book,  1988) ISDN  User-
  3779.             Network Interface Layer 3 Specification for Basic Call Control.
  3780.  
  3781.                   27.  CCITT Recommendation X.31 (Blue  Book, 1988) Support of Packet Mode
  3782.             Terminal Equipment by an ISDN.
  3783.  
  3784.             The above  documents may  be obtained  from: International  Telecommunications
  3785.             Union, Place des Nations, CH l2ll, Geneve 20 SWITZERLAND.  
  3786.  
  3787.             Miscellaneous
  3788.  
  3789.                   1.  Manufacturing Automation Protocol
  3790.  
  3791.                   2. Technical and Office Protocols, Specification Version 3.0
  3792.  
  3793.             For copies of the  two documents listed above, contact:   Corporation for Open
  3794.             Systems, 1750 Old Meadow Road, McLean, VA 22102-4306.
  3795.               
  3796.  
  3797.  
  3798.  
  3799.  
  3800.  
  3801.  
  3802.  
  3803.  
  3804.  
  3805.  
  3806.  
  3807.                                                   52
  3808.  
  3809.  
  3810.  
  3811.  
  3812.  
  3813.  
  3814.  
  3815.                                       FOREWORD TO THE APPENDICES
  3816.  
  3817.  
  3818.             Appendices  1-5  describe U.  S.  Government advanced  requirements  for which
  3819.             adequate specifications have yet  to be developed.   This section, revised  by
  3820.             the GOSIP  Advanced Requirements  Group, gives  an updated  and more  complete
  3821.             summary of protocols planned for inclusion in future versions of the document.
  3822.             Each summary states the requirements for including the protocol in GOSIP and a
  3823.             plan of work to meet those requirements.  
  3824.  
  3825.             New versions of GOSIP will be issued  no more frequently than once a year  and
  3826.             the comments  of manufacturers,  government agencies  and the  public will  be
  3827.             solicited  before each new version is released.
  3828.  
  3829.             The following protocols are candidates for inclusion in Version 3 of GOSIP.
  3830.  
  3831.                   1.  Directory Services
  3832.                   2.  Optional Class 2 Transport Protocol
  3833.                   3.  CGM
  3834.                   4.  Virtual Terminal (X3, page, scroll profiles)
  3835.                   5.  MHS extensions based on 1988 CCITT Recommendations
  3836.                   6.  FTAM extensions
  3837.                   7.  FDDI
  3838.                   8.  Network Management (Also the subject of a separate FIPS.)
  3839.                   9.  Optional Security Enhancements
  3840.                   10.  SGML 
  3841.                   11.  Manufacturing Message Specification
  3842.                   12.  Intra-domain Dynamic Routing
  3843.                   13.  EDI
  3844.  
  3845.             The following protocols are candidates for inclusion in Version 4 of GOSIP. 
  3846.  
  3847.                   1.  Transaction Processing
  3848.                   2.  Remote Database Access
  3849.                   3.  Additional Optional Security Enhancements
  3850.                   4.  Additional Network Management Functions
  3851.                   5.  Inter-domain Dynamic Routing
  3852.  
  3853.             The  purpose of  Appendices  1-5 is  to assist  federal  agencies in  planning
  3854.             decisions relating to the acquisition of implementations of OSI protocols.  
  3855.  
  3856.             Appendix 6 specifies a list of acronyms.
  3857.  
  3858.             These appendices are not part of the Federal Information Processing Standard.
  3859.  
  3860.  
  3861.  
  3862.  
  3863.  
  3864.  
  3865.  
  3866.  
  3867.  
  3868.                                                   53
  3869.  
  3870.  
  3871.  
  3872.  
  3873.  
  3874.  
  3875.  
  3876.                                          APPENDIX 1.  SECURITY
  3877.  
  3878.              
  3879.             1.1  BACKGROUND
  3880.              
  3881.             The Open Systems Interconnection Security Architecture is now an International
  3882.             Standard (IS 7498/2).  This document provides a  general architecture that may
  3883.             be used  in implementing  security  services in  OSI networks.   Five  primary
  3884.             security services are specified in the architecture as well as the  OSI layers
  3885.             at which security services could be offered.  The document also discusses many
  3886.             security mechanisms which can be used in providing the services.   
  3887.  
  3888.             The OSI Security Architecture provides a basis for developing  security but it
  3889.             does not  provide specifications  for implementing  security.   A  significant
  3890.             level of effort is  required before specifications for security  are available
  3891.             that can be used in standards.  This appendix addresses the need  for security
  3892.             standards, the status  of standards being  developed and plans for  developing
  3893.             additional required standards. 
  3894.              
  3895.             While the term "Open Systems" implies  that users of such systems intend  that
  3896.             the systems be open to others, the users always want to provide access to such
  3897.             systems  only  to authorized  users  for  authorized purposes.    Systems that
  3898.             process  sensitive and  valuable  data, especially  classified  data, must  be
  3899.             protected from  a wide variety  of threats.   Vulnerabilities of  open systems
  3900.             include unauthorized access and denial of service.  Vulnerabilities of data in
  3901.             open systems  include unauthorized  disclosure, modification  and destruction,
  3902.             both accidentally and intentionally. 
  3903.              
  3904.             Computer programs designed to obtain, modify or destroy data or to simply deny
  3905.             service to  authorized users are a  threat to networks  of computers.   Such a
  3906.             program is often called a Virus or  a Worm.  Computers which allow programs to
  3907.             be executed that  have been imported from  an external source, either  via the
  3908.             network  or through  a storage  medium, may  be vulnerable  to such  programs.
  3909.             Users  should  always have  back-up  copies of  valuable data  in  an off-line
  3910.             storage facility in case the on-line  data is modified or destroyed.   Trusted
  3911.             systems with isolation  and controlled  sharing mechanisms should  be used  to
  3912.             minimize the threat of a Virus or a Worm. 
  3913.              
  3914.             Security is an option in GOSIP.  As such, security services may be provided at
  3915.             one or more  of the layers 2,  3, 4, 6 and 7.   The Appendix 1  figure depicts
  3916.             placement of security  in the overall  profile by augmenting  Figure 3.2  with
  3917.             optional security in order  to form the Government OSI  security architecture.
  3918.             The  security  architecture described  here suggests  a  range of  choices for
  3919.             security services and their placement.  It is expected  that a subset of these
  3920.             services and layers  will adequately  satisfy specific security  requirements.
  3921.             Because  security  inherently restricts  access  and if  applied  at different
  3922.             layers  will  prohibit  interoperability,  it  is  the  responsibility  of  an
  3923.             acquisition authority to insure  that the security options chosen  provide the
  3924.             desired interoperability as well as the required security.
  3925.  
  3926.             1.2  REQUIREMENTS 
  3927.              
  3928.  
  3929.                                                   54
  3930.  
  3931.  
  3932.  
  3933.  
  3934.  
  3935.  
  3936.  
  3937.             The  primary  security  services   that  are  defined  in  the   OSI  security
  3938.             architecture are  authentication, access  control, confidentiality,  integrity
  3939.             and non-repudiation.    These are  defined  in detail  in  IS 7498/2  and  are
  3940.             summarized, with simple examples given, below: 
  3941.              
  3942.               *Data  confidentiality  services  protect against  unauthorized  disclosure.
  3943.             Protecting the details of an attempted corporate takeover is an example of the
  3944.             need for confidentiality. 
  3945.              
  3946.               *Data  integrity   services  protect   against  unauthorized   modification,
  3947.             insertion  and deletion.   Electronic  funds transfer  between banks  requires
  3948.             protection against modification of the information. 
  3949.              
  3950.               *Authentication services verify the identity  of communicating peer entities
  3951.             and the source of data.  Owners  of bank accounts require assurance that money
  3952.             will be withdrawn only by the owner. 
  3953.  
  3954.              
  3955.               *Access  control  services allow  only  authorized communication  and system
  3956.             access.    Only  financial  officers  are  authorized access  to  a  company's
  3957.             financial plans. 
  3958.              
  3959.               *Non-repudiation with proof of origin provides to the recipient proof of the
  3960.             origin of  data and protects against any attempt  by the originator to falsely
  3961.             deny sending the data  or its contents.  Non-repudiation with  proof of origin
  3962.             can be used to prove to a judge that a person signed a contract. 
  3963.              
  3964.             Requirements have been identified for government  applications for all five of
  3965.             these services, especially  the first  four.  Authentication,  confidentiality
  3966.             and integrity  services may be  implemented in layers  3, 4 and  7 of the  OSI
  3967.             architecture while  access control  and non-repudiation  services are  offered
  3968.             only at layer 7.  Applications,  such as Electronic Message Handling  Systems,
  3969.             can be  provided all  security services  at layer  7.   Providing security  at
  3970.             either layer  3 or  4  is generally  required but  not at  both  layers.   The
  3971.             selection of  security  services  at  specific layers  must  be  made  by  the
  3972.             acquisition  authority  and  depend on  the  benefits  derived  and the  costs
  3973.             encountered.   
  3974.              
  3975.             1.3  STATUS
  3976.              
  3977.             Interoperability standards are  required for security at layers 2, 3, 4, and 7
  3978.             of  the OSI architecture.   Specifications for  security at layers  3 and 4 as
  3979.             well as for  Electronic Message Handling Systems have been prepared within the
  3980.             Secure Data Network System  project.  (See NISTIR 90-4250)  Specifications for
  3981.             security  at layer 2 are being drafted by the IEEE 802.10 LAN Security Working
  3982.             Group  developing   a  Standard   for  Interoperable   LAN  Security   (SILS).
  3983.             Specifications for authentication of data have been issued in standards by the
  3984.             National Institute of Standards and  Technology (formerly the National  Bureau
  3985.             of  Standards)  (FIPS  113) and  ANSI  (ANSI  X9.9).   Specifications  for key
  3986.             management protocols have been issued in a standard by ANSI (X9.17).   
  3987.  
  3988.             The OSI Implementors' Workshop Special Interest Group in Security is reviewing
  3989.  
  3990.                                                   55
  3991.  
  3992.  
  3993.  
  3994.  
  3995.  
  3996.  
  3997.  
  3998.             the specifications of  SDNS (See NISTIRs 90-4259  and 90-4262) as they  become
  3999.             public.   It  is also  reviewing proposals  on security  management.   It  has
  4000.             reviewed several security  frameworks and architectures  that may be used  for
  4001.             future security standards development. 
  4002.              
  4003.             1.4  PLANS FOR ACHIEVEMENT
  4004.  
  4005.             The specifications  and standards  referenced above  will be  reviewed by  the
  4006.             security  staff of  NIST,  by the  members  of the  OSI  Implementors Workshop
  4007.             Security SIG and  by members of  the GOSIP committee for  inclusion in one  or
  4008.             more  of  the  following:   Federal  Information  Processing  Standards;  ANSI
  4009.             Standards; and ISO Standards.  The following outlines the plans for satisfying
  4010.             the requirements for security in OSI, the development of public specifications
  4011.             and the development of standards incorporating the specifications. 
  4012.  
  4013.             1.4.1  OSI Security Architecture
  4014.              
  4015.             The OSI  Security Architecture  (IS 7498/2)  was adopted  as an  International
  4016.             Standard in 1988.  This document is included in the Implementors Agreements as
  4017.             being the basis for all OSI security development. No further work is needed on
  4018.             this document at this time. 
  4019.               
  4020.             1.4.2  OSI Security Frameworks
  4021.              
  4022.             A set of security  frameworks of specific information  processing applications
  4023.             are planned by the  ISO/IEC/JTC 1/SC21/WG1 Security Group.   An authentication
  4024.             framework is an example of  such a framework.  The Security SIG  will continue
  4025.             to review these  frameworks for adoption in the Implementors  Agreements or to
  4026.             develop frameworks that are needed but are not in development in ISO. 
  4027.  
  4028.  
  4029.  
  4030.  
  4031.  
  4032.             1.4.3  Data Link Layer Security
  4033.              
  4034.             An IEEE  Standard for Interoperable LAN  Security is being  developed over the
  4035.             next 1-2 years by the IEEE 802.10  LAN Security Working Group.  A Standard for
  4036.             Interoperable LAN Security could be ready in 1990 for consideration by the OSI
  4037.             Implementors Workshop Security SIG. 
  4038.                
  4039.             1.4.4  Network Layer Security
  4040.                   
  4041.             The  SDNS  Network Layer  Security protocol  document  (SP3) is  available for
  4042.             public  use.   This protocol  was presented  to  ANSI in  1989.   The protocol
  4043.             encapsulates the T-PDUs just like the Transport Layer security protocol except
  4044.             that  it can  also add network  addresses to  the protocol header  for network
  4045.             routing.  The protocol may  be implemented in intermediate gateway  systems as
  4046.             well as end  systems.   A Network  Layer Security protocol  standard could  be
  4047.             ready in 1991. 
  4048.              
  4049.             1.4.5  Transport Layer Security 
  4050.  
  4051.                                                   56
  4052.  
  4053.  
  4054.  
  4055.  
  4056.  
  4057.  
  4058.  
  4059.              
  4060.             The SDNS Transport  Layer Security  protocol document (SP4)  is available  for
  4061.             public use and a FIPS is being proposed based on this work.  This protocol was
  4062.             presented to ANSI  and ISO in 1989.   The protocol encapsulates  the Transport
  4063.             Protocol Data Units, adds  an integrity code if integrity is desired, encrypts
  4064.             the  entire T-PDU if confidentiality is desired, and then puts the result in a
  4065.             SE T-PDU  (SE  stands for  security  envelope  or secure  encapsulation).    A
  4066.             receiver  that has  the correct cryptographic  key can  decrypt the  SE T-PDU,
  4067.             verify its integrity and then process the resulting T-PDU.  A  Transport Layer
  4068.             Security protocol standard could be ready in 1991. 
  4069.                
  4070.             1.4.6  Electronic Message Handling System Security 
  4071.              
  4072.             The X.400  Electronic Message Handling System security recommendations and the
  4073.             DARPA Mail Security RFC  1040 are available for public use.   The SDNS Message
  4074.             Handling Security protocol specifications  are also available for  public use.
  4075.             A standard format for secure electronic messages could be ready in 1992. 
  4076.              
  4077.             1.4.7  Cryptographic Key Management Protocols 
  4078.              
  4079.             The  ANSI  X9.17  Key  Management  Protocol, which  is  based  on  private key
  4080.             cryptographic  algorithms,  and several  public  key management  protocols are
  4081.             being reviewed by the NIST security staff.  A key management protocol based on
  4082.             public key cryptographic algorithms could be ready in 1993 for implementation.
  4083.  
  4084.  
  4085.  
  4086.  
  4087.  
  4088.  
  4089.  
  4090.  
  4091.  
  4092.  
  4093.  
  4094.  
  4095.  
  4096.  
  4097.  
  4098.  
  4099.  
  4100.  
  4101.  
  4102.  
  4103.  
  4104.  
  4105.  
  4106.  
  4107.  
  4108.  
  4109.  
  4110.  
  4111.  
  4112.                                                   57
  4113.  
  4114.  
  4115.  
  4116.  
  4117.  
  4118.  
  4119.  
  4120.                                  Figure A.1  Framework for OSI Security
  4121.  
  4122.  
  4123.  
  4124.  
  4125.  
  4126.  
  4127.  
  4128.  
  4129.  
  4130.  
  4131.  
  4132.  
  4133.  
  4134.  
  4135.  
  4136.  
  4137.  
  4138.  
  4139.  
  4140.  
  4141.  
  4142.  
  4143.  
  4144.  
  4145.  
  4146.  
  4147.  
  4148.  
  4149.  
  4150.  
  4151.  
  4152.  
  4153.  
  4154.  
  4155.  
  4156.  
  4157.  
  4158.  
  4159.  
  4160.  
  4161.  
  4162.  
  4163.  
  4164.  
  4165.  
  4166.  
  4167.  
  4168.  
  4169.  
  4170.  
  4171.  
  4172.  
  4173.                                                   58
  4174.  
  4175.  
  4176.  
  4177.  
  4178.  
  4179.  
  4180.  
  4181.                                  APPENDIX 2.  SYSTEM AND ARCHITECTURE
  4182.  
  4183.  
  4184.             2.1  Network Management
  4185.  
  4186.             OSI management functionality  supports the location and  correction of faults,
  4187.             the establishment and adjustment of configurations, the measurement and tuning
  4188.             of performance, the  management of security,  and collection and reporting  of
  4189.             billing and  accounting information.   Such  functionality is  in end  systems
  4190.             (hosts), intermediate  systems (routers),  and other  network elements  (e.g.,
  4191.             network services, bridges,  switches, modems, and multiplexors).   The primary
  4192.             goal for a  Federal Government network  management specification is to  create
  4193.             the ability for managing multi-vendor computer and telecommunications networks
  4194.             remotely without undue use of proprietary management protocols.  The scope  of
  4195.             a network management specification for use by the U.S. Government will include
  4196.             protocols for exchanging management information and  the definition and format
  4197.             of information to be exchanged. 
  4198.  
  4199.             Note:    The  primary  vehicle  for  this  specification  will  be  a  Federal
  4200.             Information Processing Standard  (FIPS).  This  FIPS will reference GOSIP  and
  4201.             will be  referenced by  GOSIP.   (The FIPS  is discussed  further below  under
  4202.             "Plan".)
  4203.  
  4204.             Requirements
  4205.  
  4206.             Requirements for  OSI network management are described in detail within a NIST
  4207.             report, Management  of Networks  Based on Open  Systems Interconnection  (OSI)
  4208.             Standards: Functional Requirements and Analysis (NIST Special Publication 500-
  4209.             175,  November   1989).    Requirements   exist  for  an   overall  management
  4210.             architectural  framework  model  including fault,  accounting,  configuration,
  4211.             security, and performance management services. 
  4212.  
  4213.             Status
  4214.  
  4215.             The OSI management standards are in an intermediate stage of their development
  4216.             and  are  progressing  rapidly.    Key  areas  for  management  standards  are
  4217.             architecture, protocols,  system management  functions, and  the structure  of
  4218.             management information.   The following table  lists the latest available  ISO
  4219.             schedule for management standards approved at the Sixth SC 21/WG 4  Meeting in
  4220.             Florence, October 31 - November 9, 1989.
  4221.  
  4222.                                                                                  TARGET
  4223.             DATES
  4224.  
  4225.                                                                         DP     DIS    IS
  4226.             Management Architecture
  4227.             Management Framework                                        9/86  6/87  10/88
  4228.             Systems Management Overview                                             7/90
  4229.             4/91
  4230.  
  4231.             Management Protocol
  4232.             Common Management Information Service                                    
  4233.  
  4234.                                                   59
  4235.  
  4236.  
  4237.  
  4238.  
  4239.  
  4240.  
  4241.  
  4242.             1/90   
  4243.               Addendum 1:  CancelGet                                                9/89
  4244.             7/90
  4245.               Addendum 2:  Add/Remove                                               9/89
  4246.             7/90
  4247.             Common Management Information Protocol
  4248.             1/90
  4249.                Addendum 1:  CancelGet                                               9/89
  4250.             7/90
  4251.                Addendum 2:  Add/Remove                                              9/89
  4252.             7/90
  4253.  
  4254.             Structure of Management Information
  4255.             Part 1:  Management Information Model                                   5/89
  4256.             1/90   1/91
  4257.             Part 2:  Definition of Management                                       7/90
  4258.             4/91
  4259.                   Information       
  4260.             Part 4:  Guidelines for the Definition                                  11/89
  4261.             1/91   1/92
  4262.                   of Managed Objects
  4263.                                                                               TARGET DATES
  4264.  
  4265.                                                                           DP   DIS    IS
  4266.             Management Functions
  4267.             Configuration Management 
  4268.               Systems Management - Part 1:                                           
  4269.             7/90   7/91
  4270.                 Object Management Function                 
  4271.               Systems Management - Part 2:                                          7/90
  4272.             7/91
  4273.                 State Management Function
  4274.               Systems Management - Part 3:                                           
  4275.             7/90   7/91
  4276.                 Relationship Management Function
  4277.             Fault Management
  4278.               Systems Management - Part 4:                                           
  4279.             7/90   7/91
  4280.                 Alarm Reporting Function
  4281.               Systems Management - Part 5:                                           
  4282.             7/90   7/91
  4283.                 Event Report Management Function
  4284.               Systems Management - Part *:                                           7/90
  4285.             4/91   4/92
  4286.                 Confidence and Diagnostic Testing Function
  4287.               Systems Management - Part 6:                                          11/89
  4288.             7/90   7/91
  4289.                 Log Control Function
  4290.             Security Management                                  
  4291.               Systems Management - Part 7:                                    11/89 7/90
  4292.             7/91
  4293.                 Security Alarm Reporting Function
  4294.  
  4295.                                                   60
  4296.  
  4297.  
  4298.  
  4299.  
  4300.  
  4301.  
  4302.  
  4303.               Systems Management - Part *:                                     7/90 4/91
  4304.             4/92
  4305.                 Security Audit Trail Function
  4306.             Accounting Management                                              
  4307.               Systems Management - Part *:                                     7/90 4/91
  4308.             4/92
  4309.                 Accounting Metering Function
  4310.             Performance Management
  4311.               Systems Management - Part *:                                     7/90 4/91
  4312.             4/92
  4313.                 Workload Monitoring Function
  4314.               Systems Management - Part *:                                           7/90
  4315.             4/91   4/92
  4316.                 Measurement Summarization Function
  4317.  
  4318.             As can be seen from the above  schedule, there are several important standards
  4319.             that have now reached, or soon will reach, International Standard (IS) status.
  4320.             However, many others are still two years away from IS.   Still others that are
  4321.             planned, e.g., Software  Management (including "down-line load"), have not yet
  4322.             been  added  to  the schedule.    It  is  important  to note  that  the  Draft
  4323.             International Standards (DISs)  scheduled to be available  by the end  of 1990
  4324.             comprise a  subset that  will make  it possible  for vendors  to build  useful
  4325.             systems to solve many immediate network management problems.
  4326.  
  4327.             Standards for the specification of managed objects are now being developed  by
  4328.             ISO,  ANSI, CCITT, and the IEEE,  as well as by  the Internet Engineering Task
  4329.             Force of  the Internet  Activities Board  (for management  of TCP/IP  oriented
  4330.             networks).    In   general,  full  specifications  and  standards  from  these
  4331.             organizations are expected  to lag the  above SC21/WG4 management schedule  by
  4332.             more than a year.
  4333.  
  4334.             Another  important aspect  of  network management  standards  activity is  the
  4335.             development of implementation agreements (IAs).  The network management SIG of
  4336.             the NIST OIW  is developing  IAs based  upon the  emerging network  management
  4337.             standards.    These  agreements are  being  developed  according  to a  phased
  4338.             approach that aligns with  the ISO standards as  they progress from DP  to IS.
  4339.             The  OSI/NM   Forum  is   also  developing   a  set   of  agreements   (termed
  4340.             specifications) for  network management.   These agreements, based  on earlier
  4341.             ISO  documents and original Forum work,  are to be used  as a basis for Forum-
  4342.             sponsored interoperable management demonstrations planned for 1990 and beyond.
  4343.             Both formal and informal liaison between the NMSIG of the OIW and the NM Forum
  4344.             has proved mutually beneficial in advancing  each set of agreements, including
  4345.             identifying and correcting errors and omissions. 
  4346.  
  4347.             Plan
  4348.  
  4349.             There is an urgent need today for products to manage multi-vendor computer and
  4350.             telecommunications networks.   The  U.S. Government  requires initial  network
  4351.             management  specifications  that  provide a  useful  subset  of  the full  OSI
  4352.             management functionality.   It is desirable  to specify the initial  subset in
  4353.             such  a way that it is easy to add other capabilities to reach the full set of
  4354.             management  functionality.    Such additional  functionality  may  include the
  4355.  
  4356.                                                   61
  4357.  
  4358.  
  4359.  
  4360.  
  4361.  
  4362.  
  4363.  
  4364.             management of future technologies  such as ISDN and FDDI, and  may include new
  4365.             management services such as software management and time management. 
  4366.  
  4367.             The U.S. Government intends to propose an initial FIPS based on the OIW stable
  4368.             network  management IAs.   The OIW will  include at most the  following in its
  4369.             agreements to be completed in 1990 (from phase one of the OIW IAs):
  4370.              
  4371.                 Management Functions: 
  4372.                   Object  Management,  State  Management, Relationship  Management,  Error
  4373.                   Reporting and Event Control 
  4374.  
  4375.                 Management Information: 
  4376.                   Information Model, Naming, Guidelines and  Template for Defining Managed
  4377.                   Objects 
  4378.  
  4379.                 Management Communication: 
  4380.                   CMIS/P, Association Policies, and Services Required 
  4381.  
  4382.                 Management Objects: 
  4383.                   Support  Objects  required   for  above  and  selected   Managed  Object
  4384.                   Definitions under development by the OSI MIB WG 
  4385.  
  4386.                 Conformance Criteria:
  4387.                   TBD depending on the progress of relevant ISO documents. 
  4388.  
  4389.             It is  planned  that the  initial network  management FIPS  will  be based  on
  4390.             portions of  the above  phase one stable  agreements.   The FIPS  will include
  4391.             specifications for a  management protocol based on OIW IAs  for CMIS/CMIP, and
  4392.             it  will  include management  function specifications  based  on the  OIW IAs.
  4393.             Also, the  FIPS  will include  a  library of  management  objects (MIL).    In
  4394.             addition, other portions of the agreements may be cited in the FIPS.
  4395.  
  4396.             GOSIP profiles will  be cited in the  FIPS to specify the  protocol stack upon
  4397.             which management information will be conveyed  and to include OSI applications
  4398.             suitable to support management of networks. 
  4399.  
  4400.             Once an initial management FIPS has been established, portions of future GOSIP
  4401.             versions  may  reference management  FIPS  as  appropriate.   For  example, to
  4402.             specify  management  of  network  end  system  (host) computers,  GOSIP  might
  4403.             reference the Network  Management FIPS sections on  the use of CMIS/CMIP  as a
  4404.             method for conveying information  and sections on system management  functions
  4405.             for specific management services.   GOSIP might also reference  the management
  4406.             FIPS for appropriate managed object definitions.   Likewise for the management
  4407.             of  network routers,  GOSIP might  reference the  FIPS for  use of  CMIS/CMIP,
  4408.             management functions and managed object definitions.  
  4409.  
  4410.             These are possible initial examples.  As both the FIPS and GOSIP mature, GOSIP
  4411.             will  likely  make  many  additional  references  to  newer  versions  of  the
  4412.             management FIPS.   (And  the FIPS  can be  expected to additionally  reference
  4413.             newer versions of GOSIP as well.)
  4414.  
  4415.             2.2  REGISTRATION
  4416.  
  4417.                                                   62
  4418.  
  4419.  
  4420.  
  4421.  
  4422.  
  4423.  
  4424.  
  4425.  
  4426.             OSI  Registration  procedures   are  the  key  to   creating  globally  unique
  4427.             identifiers  for  OSI  objects.    Most  OSI  objects  are  identified  via  a
  4428.             hierarchically structured  label.  Specific procedures must  be established to
  4429.             ensure that  GOSIP identifiers fit  within an internationally  recognized plan
  4430.             and uniquely identify GOSIP objects.
  4431.             Requirement
  4432.  
  4433.             Procedures  are  required  for  the  registration  of  OSI  objects,  such  as
  4434.             organization  numbers and  names.   The specific  complete list of  objects is
  4435.             subject to  further study  and is  likely to  evolve over  time, as  directory
  4436.             services  are  adopted.   For  the  first version  of  GOSIP,  procedures were
  4437.             required for registration of organization identifiers for use in NSAPs, labels
  4438.             for electronic mail private body parts,  and organization names for electronic
  4439.             mail  addresses.   The  third  version of  GOSIP  will require  extending  the
  4440.             procedures to include directory distinguished names.  An immediate requirement
  4441.             not specific  to GOSIP is registration  procedures for objects defined  in the
  4442.             OSI Implementor's Agreements.
  4443.  
  4444.             Status
  4445.  
  4446.             A standard for registration procedures is under  development in ISO.  The NIST
  4447.             is already maintaining a  small registration service for OSINET members.   The
  4448.             NIST  has secured three international code  designators (ICDs) as follows:  1)
  4449.             four (4) allocated to OSINET and the NIST/OSI Implementor's Workshop;  2) five
  4450.             (5) allocated to the U. S. Government,  and 3) fourteen (14) allocated to  the
  4451.             OSI Implementors' Workshop (OIW). 
  4452.  
  4453.             Plan
  4454.  
  4455.             The NIST is updating the GOSIP User's Guide for  publication with Version 2 of
  4456.             GOSIP.  One section of the guide will detail GOSIP registration procedures.  A
  4457.             registration SIG in the NIST OSI Implementors' Workshop has identified objects
  4458.             requiring registration and established detailed procedures for registering the
  4459.             objects.
  4460.  
  4461.             2.3  ADDRESSING
  4462.  
  4463.             GOSIP  network  addressing  is  limited  to  defining  NSAPs.    The  existing
  4464.             assumption is that NSAPs will be retrievable from a directory service and that
  4465.             each NSAP  will address a  single host.  Nothing  within GOSIP is  designed to
  4466.             preclude multi-homed or  mobile end systems.   The problem is that  no routing
  4467.             protocol exists  to deal  with mobile  hosts at  the speed  required for  some
  4468.             applications.  At the present time,  there is no definition for the  semantics
  4469.             and syntax of multi-cast addressing within the network layer.
  4470.  
  4471.             Requirement
  4472.  
  4473.             Multi-cast addressing  is required to support operation  on broadcast networks
  4474.             with connectionless protocols.
  4475.  
  4476.             Status
  4477.  
  4478.                                                   63
  4479.  
  4480.  
  4481.  
  4482.  
  4483.  
  4484.  
  4485.  
  4486.  
  4487.             No work is underway in this area.
  4488.  
  4489.             Plan
  4490.  
  4491.             Study  inclusion of  multi-cast NSAPs  for operation  over broadcast  networks
  4492.             (e.g., local networks) in conjunction  with connectionless transport, network,
  4493.             and data link protocols.
  4494.  
  4495.  
  4496.  
  4497.  
  4498.  
  4499.  
  4500.  
  4501.  
  4502.  
  4503.  
  4504.  
  4505.  
  4506.  
  4507.  
  4508.  
  4509.  
  4510.  
  4511.  
  4512.  
  4513.  
  4514.  
  4515.  
  4516.  
  4517.  
  4518.  
  4519.  
  4520.  
  4521.  
  4522.  
  4523.  
  4524.  
  4525.  
  4526.  
  4527.  
  4528.  
  4529.  
  4530.  
  4531.  
  4532.  
  4533.  
  4534.  
  4535.  
  4536.  
  4537.  
  4538.  
  4539.                                                   64
  4540.  
  4541.  
  4542.  
  4543.  
  4544.  
  4545.  
  4546.  
  4547.                                       APPENDIX 3.  UPPER LAYERS 
  4548.  
  4549.  
  4550.             3.1  X.400 EXTENSIONS
  4551.  
  4552.             Message Handling System specifications in Version 2 of GOSIP are based  on the
  4553.             1984 CCITT Recommendations.   GOSIP MHS extensions will be based  on the CCITT
  4554.             1988  Recommendations.    These   recommendations  provide  new   capabilities
  4555.             including  security,  delivery  to  a  physical  delivery service,  use  of  a
  4556.             directory service, delivery  to a message store, and an OSI architecture which
  4557.             includes ACSE and the Presentation layer.
  4558.  
  4559.             Requirements
  4560.  
  4561.             A requirement  exists for  MHS security  features such  as message  originator
  4562.             authentication, checks  against  unauthorized disclosure  and verification  of
  4563.             content integrity.  It is also highly desirable to have message store delivery
  4564.             which will allow personal  computers without full User Agent  functionality to
  4565.             have access to MHS services.  The DOD requires that military precedence levels
  4566.             and  preemption features  be incorporated  into the  Message Handling  Systems
  4567.             standard  and that a  method be developed  of passing this  information to the
  4568.             connectionless network layer protocol for processing.
  4569.  
  4570.             Status
  4571.  
  4572.                 A.    Standards   -   The  1988  CCITT MHS  Recommendations were  formally
  4573.             approved in late 1988.
  4574.  
  4575.                 B.  Implementors' Agreements  -  In 1989, the MHS SIG issued implementors'
  4576.             agreements which provided a minimally conformant 1988 Message Handling System.
  4577.             These  implementors'  agreements do  not  include significant  additional user
  4578.             services, but allow interworking  with implementations conforming to the  NIST
  4579.             Stable Implementation Agreements  for CCITT 1984 X.400-based  Message Handling
  4580.             Systems and provide a firm basis for the introduction of further 1988 services
  4581.             and features.  Further implementors' agreements based on CCITT  1988 X.400 are
  4582.             expected in 1990.
  4583.  
  4584.             Plan
  4585.  
  4586.             As an interim measure,  NSA and NIST should determine whether  the SDNS method
  4587.             of sending security information in a  new special-purpose User Agent satisfies
  4588.             all GOSIP advanced security  requirements for electronic mail.   This approach
  4589.             would  allow  security information  to  be  sent on  Message  Handling Systems
  4590.             implemented according to  the CCITT  1984 Recommendations.   However, the  new
  4591.             User Agent would not be based on an international standard.
  4592.  
  4593.             There already exists the capability of sending and receiving X.400 mail from a
  4594.             personal computer attached  to a  host by using  terminal emulation  software.
  4595.             The User Agent  is co-located  with the MTA  and the terminal  interface is  a
  4596.             local matter.   The GOSIP Advanced Requirements Group plans  to investigate to
  4597.             what extent this architecture satisfies current government requirements.
  4598.  
  4599.  
  4600.                                                   65
  4601.  
  4602.  
  4603.  
  4604.  
  4605.  
  4606.  
  4607.  
  4608.             There is also  a proposal to  include a message  store (i.e., standard  remote
  4609.             User Agent)  capability in a  future MHS implementors'  agreement.   A message
  4610.             store would provide a standard software  package with standard error recovery.
  4611.             When implementors' agreements for message store are adopted, the functionality
  4612.             in those agreements will be incorporated into GOSIP.
  4613.  
  4614.             The  DoD requirement for  expansion of precedence levels  will be forwarded to
  4615.             the  CCITT  committee  on  Message  Handling  Systems.    The  GOSIP  Advanced
  4616.             Requirements  Group  will  request  the  NIST/OSI  Implementors'  Workshop  to
  4617.             determine how Application-level precedents  can be passed to the  lower layers
  4618.             for processing.
  4619.  
  4620.  
  4621.  
  4622.             3.2  FTAM (FILE TRANSFER, ACCESS AND MANAGEMENT)
  4623.  
  4624.             The File Transfer,  Access and Management protocol and service  allow users on
  4625.             different networks  to communicate  about files (and  transfer files)  without
  4626.             requiring that one  user know the  detailed file characteristics of  the other
  4627.             user.  A generic  file organization is defined for  communication; elements of
  4628.             this virtual file model are mapped to corresponding elements of the local file
  4629.             system.  A  comprehensive set of file attributes and  file activity attributes
  4630.             are defined; in  addition, a  large number of  actions is possible  on a  wide
  4631.             variety of file types.
  4632.  
  4633.             Requirement
  4634.  
  4635.             Implementation profiles are defined for user  requirements as follows:  simple
  4636.             file  transfer, positional  file  transfer, full  file  transfer, simple  file
  4637.             access,  full  file  access,  and  management.   Each  implementation  profile
  4638.             contains  a different  combination of document  types, attributes  and service
  4639.             classes.  An FTAM implementation for  the GOSIP should require support of  the
  4640.             positional file  transfer (which includes  simple file transfer),  simple file
  4641.             access  and  management implementation  profiles.   Future  versions  of GOSIP
  4642.             should  include  overlapped  access,  filestore   management  (including  file
  4643.             directory query  capability), error  recovery capability, concurrency  control
  4644.             capability, and File Access Data Unit (FADU) locking capability.
  4645.  
  4646.             Status
  4647.  
  4648.                 A.  Standards - FTAM  has been released as an International Standard  from
  4649.             ISO;  currently  FTAM  comprises  five  parts: general  introduction,  virtual
  4650.             filestore definition,  file service  definition, file protocol  specification,
  4651.             and protocol  information  conformance  statement  proforma.   There  are  two
  4652.             prospective  addenda  which are  overlapped  access and  filestore management.
  4653.             Filestore  management  should reach  IS status  in  late 1991,  and overlapped
  4654.             access should reach IS status in early 1992.
  4655.  
  4656.                 B.   Implementors' Agreements  -  FTAM  Phase 2  (based  on IS  text)  was
  4657.             completed as of December 1988, and maintained since then with the inclusion of
  4658.             several errata.  This agreement provides for all core services defined  in the
  4659.             FTAM standard except  for restart, recovery  and concurrency.  Facilities  for
  4660.  
  4661.                                                   66
  4662.  
  4663.  
  4664.  
  4665.  
  4666.  
  4667.  
  4668.  
  4669.             full file transfer and record-level access are provided; three different FTAM,
  4670.             and four different NIST document types are  defined.  FTAM Phase 2 is included
  4671.             in Version 3 of the workshop agreements, available after December 1989.   FTAM
  4672.             Phase 3 provides restart, recovery and concurrency capabilities, and  enlarges
  4673.             on the set of  document types currently defined.  FTAM Phase  3 is complete as
  4674.             of  March 1990.  FTAM Phase 2 Agreements are upwardly compatible to FTAM Phase
  4675.             3 Agreements at the intersection of their functional capabilities.
  4676.  
  4677.             Plan
  4678.  
  4679.             FTAM Phase 2 is currently included in versions 1 and  2 of GOSIP; reference is
  4680.             made  to the  Phase  2  FTAM (based  on  IS) as  it  appears  in the  workshop
  4681.             agreements.  A  file directory service capability  is planned for in  a future
  4682.             version of GOSIP; it is  also anticipated that a number of new  document types
  4683.             will be included  in the future.   Possibly, full file transfer  and full file
  4684.             access  implementation  profiles  will be  mandated.    Recovery, restart  and
  4685.             concurrency control capabilities may also be required.  It is anticipated that
  4686.             Version  3 of  GOSIP will  mandate  the FTAM  Phase 3  specification  from the
  4687.             Workshop Agreements. NIST personnel  will work with the FTAM  Special Interest
  4688.             Group at the  NIST/OSI Implementors' Workshop  to expedite the development  of
  4689.             implementation  agreements  and  to insure  that  government  requirements are
  4690.             included.
  4691.  
  4692.             3.3  VIRTUAL TERMINAL
  4693.  
  4694.             The  Basic  Class Virtual  Terminal  Protocol  allows terminals  and  hosts on
  4695.             different networks to  communicate without  requiring that one  side know  the
  4696.             terminal characteristics handled by the other side.  A generic set of terminal
  4697.             characteristics is defined for communication which is mapped to local terminal
  4698.             characteristics for  display.  An addendum to Basic  Class VT provides a forms
  4699.             mode capability.
  4700.  
  4701.  
  4702.  
  4703.             Requirement
  4704.  
  4705.             The service options  to be  selected include  type of negotiation  and the  VT
  4706.             profiles to be specified.   Additional implementation profiles for  GOSIP will
  4707.             include profiles  for page and  scroll terminals  in addition to  the existing
  4708.             TELNET and forms profiles.  No negotiation capability is required.
  4709.  
  4710.             Status
  4711.  
  4712.                 A.  Standards -  All comments on Basic Class VT and on  addendum 1 (forms)
  4713.             have been resolved and the service and protocol documents for Basic  Class and
  4714.             the addendum have been merged.
  4715.  
  4716.                 B.  Implementors'  Agreements - Stable  agreements were completed  for the
  4717.             TELNET, Transparent, and Forms  profiles in December 1988.   Stable Agreements
  4718.             for the X3 profile were completed in December 1989.
  4719.  
  4720.             Plan
  4721.  
  4722.                                                   67
  4723.  
  4724.  
  4725.  
  4726.  
  4727.  
  4728.  
  4729.  
  4730.  
  4731.             Version 3 of  GOSIP is expected to  include the X3, scroll  and page profiles.
  4732.             Additional options may  be added to the  TELNET profile.  NIST  personnel will
  4733.             work with the VT Special Interest Group in the NIST/OSI Implementors' Workshop
  4734.             to expedite the  development of implementation  agreements and to insure  that
  4735.             government requirements are included.
  4736.  
  4737.             3.4  THE DIRECTORY
  4738.  
  4739.             A  directory  is a  collection of  attributes  (i.e., information)  about, and
  4740.             relations  between,  a named  set  of  addressable objects  within  a specific
  4741.             context.  A  directory can be viewed  as a data  base containing instances  of
  4742.             record types.  The most typical relationship  between a directory user and the
  4743.             directory itself is  that of an information user  and an information provider.
  4744.             The user supplies  an unambiguous or ambiguous  key to the directory,  and the
  4745.             directory returns the information labeled by the  key.  The directory user may
  4746.             filter the available information to access only the most essential fields.
  4747.  
  4748.             Requirement
  4749.  
  4750.             The requirements for  a GOSIP directory service  are much too  complicated and
  4751.             voluminous  to  include here.    The  NIST  has  developed a  separate  report
  4752.             specifying the requirements.  From the complete  requirement set, the NIST has
  4753.             identified an initial  subset for inclusion into  GOSIP.  In summary,  for the
  4754.             initial directory, requirements  include:   1) functions provided  by the  DoD
  4755.             "whois" service  (a name  to data  record mapping),  and the  DoD domain  name
  4756.             service (host name to network address mapping), 2) service name to T-selector,
  4757.             S-selector,  and P-selector  mapping, 3)  inclusion of  a  host's capabilities
  4758.             within the host  directory entry, and 4)  the ability to resolve  mailing list
  4759.             names  into  a  set of  electronic  mail  addresses.   For  the  initial GOSIP
  4760.             directory, access  control, simple  authentication, and  replication are  also
  4761.             required.
  4762.  
  4763.             Status
  4764.  
  4765.             The Directory is an IS  in ISO (ISO 9594) and has been issued  by CCITT as the
  4766.             X.500 series of  Recommendations.   Workshop Agreements exist  based on  these
  4767.             documents.  ISO  and CCITT  are jointly developing  extensions to the  current
  4768.             standard in areas where it is known  to be deficient, such as access  control,
  4769.             replication, and the information model.   Additional implementation agreements
  4770.             are needed to cover the extensions.
  4771.  
  4772.             Plan
  4773.  
  4774.             The plan is to  improve the directory implementor agreements as  necessary and
  4775.             to get  needed changes  into the  ISO and  X.500 versions  of the  standard to
  4776.             support the initial GOSIP requirements.  These goals should be accomplished in
  4777.             1991 and 1992  so that an initial directory specification can be included in a
  4778.             subsequent version of GOSIP.
  4779.  
  4780.             3.5  REMOTE DATABASE ACCESS
  4781.  
  4782.  
  4783.                                                   68
  4784.  
  4785.  
  4786.  
  4787.  
  4788.  
  4789.  
  4790.  
  4791.             Remote  Database  Access   (RDA)  allows   the  interconnection  of   database
  4792.             applications  among  heterogeneous  environments  by  providing  standard  OSI
  4793.             Application  layer  protocols  to  establish  a  remote connection  between  a
  4794.             database client and a database server.   The client is acting on behalf of  an
  4795.             application program while the server is interfacing to a process that controls
  4796.             data transfers to and from a database.
  4797.  
  4798.             Requirement
  4799.  
  4800.             There is a strong  requirement to share information among  Database Management
  4801.             Systems from different  vendors which  are widespread in  both government  and
  4802.             industry.  The  Remote Database Access  protocol allows  that data sharing  by
  4803.             providing a neutral "language" by which heterogeneous systems can communicate.
  4804.  
  4805.             An  extension of  the above requirement  is the need  for distributed database
  4806.             capability.  This will be achieved in  the long-term by extending the existing
  4807.             RDA model,  and through RDA's  harmonization with  the Transaction  Processing
  4808.             protocol.
  4809.  
  4810.             Status
  4811.  
  4812.             The RDA standard  is specified in two  documents, a generic RDA  for arbitrary
  4813.             database  connection  and  an  SQL  specialization  for  connecting  databases
  4814.             conforming  to the  standard  database language  SQL.   Both  the generic  RDA
  4815.             standard and the RDA specialization for  SQL include functionality required by
  4816.             Federal agencies.
  4817.  
  4818.             The generic RDA  standard reached DP status  in 1987 and is  expected to reach
  4819.             DIS status in 1990.  The RDA specialization for SQL is also  expected to reach
  4820.             DP  status in 1990.   Final adoption  of ISO International  Standards for both
  4821.             documents is expected in 1992.
  4822.  
  4823.             Plan
  4824.  
  4825.             Vendors, particularly SQL vendors, plan to have implementations  conforming to
  4826.             the ISO International Standard  available at the  earliest possible time.   An
  4827.             RDA SIG  was formed  within the  NIST OSI  Implementors' Workshop  in 1989  to
  4828.             assist in this process.
  4829.  
  4830.             3.6  TRANSACTION PROCESSING
  4831.  
  4832.             Requirement
  4833.  
  4834.             The  specific  requirements  within  the  U.  S.  Government  for  transaction
  4835.             processing are still under investigation.
  4836.  
  4837.             Status
  4838.  
  4839.             Current plans are for Transaction  Processing to move to IS status  in 1990 or
  4840.             in 1991.
  4841.  
  4842.             Plan
  4843.  
  4844.                                                   69
  4845.  
  4846.  
  4847.  
  4848.  
  4849.  
  4850.  
  4851.  
  4852.  
  4853.             NIST  is working  with Federal  agencies to  determine transaction  processing
  4854.             requirements and  is representing  the interests  of Federal  agencies in  the
  4855.             national and  international standards committees.   The first step  is for the
  4856.             federal  agencies  that  have transaction  processing  requirements  to become
  4857.             knowledgeable about the  TP services  specified in the  evolving TP  standards
  4858.             documents  and to determine  whether these  services meet  the needs  of their
  4859.             organization.    NIST is  willing  to assist  other  federal  agencies in  the
  4860.             process.
  4861.  
  4862.             A Transaction Processing SIG has been formed within the NIST/OSI Implementors'
  4863.             Workshop. 
  4864.  
  4865.  
  4866.  
  4867.             3.7  ELECTRONIC DATA INTERCHANGE
  4868.  
  4869.             Electronic  Data Interchange  (EDI) describes  the  rules and  procedures that
  4870.             allow computers to send  and receive business information in  electronic form.
  4871.             Business information  includes the full  range of information  associated with
  4872.             buyer/seller  relationships (e.g.,  invoices,  Customs declarations,  shipping
  4873.             notices, purchase orders).
  4874.  
  4875.             Requirements
  4876.  
  4877.             The Office of  Management and Budget is proposing to issue a guidance document
  4878.             that states that  Federal agencies shall,  to the maximum extent  practicable,
  4879.             make   use   of   Electronic   Data    Interchange   with   supporting   GOSIP
  4880.             telecommunications   networks   for   the   processing   of   business-related
  4881.             transactions.
  4882.  
  4883.             Status
  4884.  
  4885.                 A.   Standards - 1)   ANSI committee X12  has developed and  is developing
  4886.             standard formats for business-related messages.  There is also an ISO standard
  4887.             (IS  9735) for Electronic Data for Administration, Commerce and Transportation
  4888.             (EDIFACT).  The JTC1  special working group on EDI is  developing a conceptual
  4889.             model for Electronic  Data Interchange.  2)  CCITT Study Group VII established
  4890.             a Rapporteur Group to work on a  solution on how to perform EDI using  Message
  4891.             Handling Systems.   The group completed  work on a  set of recommendations  in
  4892.             June  1990.    This group  established  a  new  content  type for  EDI  and  a
  4893.             corresponding content protocol  (currently designated PEDI).  PEDI  will provide
  4894.             service elements and  heading fields for EDI  similar to those provided  by P2
  4895.             for interpersonal messages.
  4896.  
  4897.                 B.  Implementors'  Agreements -   The  NIST Workshop  Agreements currently
  4898.             contains basic guidelines     for  adopting 1984  X.400  as  the interim  data
  4899.             transfer mechanism between EDI applications.
  4900.  
  4901.             Plan
  4902.  
  4903.             If products based on the CCITT Interim Recommendations are available  in 1992,
  4904.  
  4905.                                                   70
  4906.  
  4907.  
  4908.  
  4909.  
  4910.  
  4911.  
  4912.  
  4913.             EDI will  be included in Version 3 of GOSIP;   Otherwise, EDI is scheduled for
  4914.             inclusion in Version 4 of GOSIP.
  4915.  
  4916.             3.8  MMS SERVICES
  4917.  
  4918.             The  Manufacturing Message  Specification  (MMS) application  can  be used  to
  4919.             obtain  and/or  manipulate  objects related  to  a  manufacturing environment.
  4920.             These objects  include, but  are not  limited to,  variables semaphores,  data
  4921.             types,  and  journals.    Although  MMS   was  designed  for  a  manufacturing
  4922.             environment, these objects have applicability outside of manufacturing.
  4923.  
  4924.             Requirements
  4925.  
  4926.             Although the government  is not a primary manufacturer,  MMS has usefulness in
  4927.             the acquisition  of point of measurement  quality data, in  military depots at
  4928.             the Department of Energy,  and Department of Defense sites.  Additionally, the
  4929.             Deep Space  Network Data  Systems group  of the  Jet Propulsion  Laboratory is
  4930.             investigating the use of MMS for on-board control and telemetry.
  4931.  
  4932.             Status
  4933.  
  4934.             MMS is currently at the IS level in ISO and has implementors' agreements ready
  4935.             for inclusion in the NIST/OSI Stable Implementor Agreements in 1990.
  4936.  
  4937.             There are implementations available based upon DIS-9506(MMS) which are already
  4938.             installed.   A  mechanism for backwards  compatibility has been  agreed and is
  4939.             ready  to progress into  the Stable Agreements  document.  Work  is ongoing to
  4940.             establish agreements on all 86 services that are contained within MMS.
  4941.  
  4942.  
  4943.             Plan
  4944.  
  4945.             The  plan is  to  augment  and improve  the  MMS  implementors' agreements  as
  4946.             required.  Additionally, abstract test cases will be reviewed and generated as
  4947.             necessary to further refine the definition  of MMS conformance.  This work  is
  4948.             ongoing with anticipated  completion of a subset  of services in 1990  so that
  4949.             MMS can be included in Version 3 of GOSIP. 
  4950.  
  4951.             3.9  INFORMATION RETRIEVAL
  4952.  
  4953.             Information retrieval supports the open interconnection of database users with
  4954.             database  providers  by  specifying  an OSI  application  layer  protocol  for
  4955.             intersystem  search  and  retrieval of  records  from  a remote  bibliographic
  4956.             database.
  4957.  
  4958.             Requirement
  4959.  
  4960.             Information retrieval functionality is required by Federal agencies which need
  4961.             to retrieve information from remote bibliographic databases.
  4962.  
  4963.             Status
  4964.  
  4965.  
  4966.                                                   71
  4967.  
  4968.  
  4969.  
  4970.  
  4971.  
  4972.  
  4973.  
  4974.             The OSI Information  Retrieval service and protocol  is specified in the  ANSI
  4975.             standard: Z39.50-1988 - Information Retrieval Service Definition and Protocols
  4976.             Specification  for Library Applications.   A  corresponding ISO  standard (ISO
  4977.             10162  and  10163:  Search  and  Retrieve  Service  Definition  and   Protocol
  4978.             Specification)  has  reached  DIS status.    Final  adoption  as international
  4979.             standards is expected by early 1991.
  4980.  
  4981.             Plan
  4982.  
  4983.             Vendors are now  developing implementations  conforming to Z39.50.   A  Z39.50
  4984.             implementor's group has  been formed, represented  by more than 20  companies.
  4985.             Options will be investigated to include bibliographic  searching within GOSIP.
  4986.             Agencies  are   encouraged  to   bring  forth   other  information   retrieval
  4987.             requirements.
  4988.  
  4989.  
  4990.  
  4991.  
  4992.  
  4993.  
  4994.  
  4995.  
  4996.  
  4997.  
  4998.  
  4999.  
  5000.  
  5001.  
  5002.  
  5003.  
  5004.  
  5005.  
  5006.  
  5007.  
  5008.  
  5009.  
  5010.  
  5011.  
  5012.  
  5013.  
  5014.  
  5015.  
  5016.  
  5017.  
  5018.  
  5019.  
  5020.  
  5021.  
  5022.  
  5023.  
  5024.  
  5025.  
  5026.  
  5027.                                                   72
  5028.  
  5029.  
  5030.  
  5031.  
  5032.  
  5033.  
  5034.  
  5035.                                      APPENDIX 4.  EXCHANGE FORMATS
  5036.  
  5037.  
  5038.             The  following  standards are  not OSI  standards,  but they  provide services
  5039.             required by Federal agencies  and the format information that they specify can
  5040.             be transferred by OSI Application layer protocols, such as FTAM and MHS.
  5041.  
  5042.             4.1  ODA EXTENSIONS
  5043.  
  5044.             ODA allows  for the  interchange of  compound documents (documents  containing
  5045.             text, facsimile, and  graphics) which have been generated by  diverse types of
  5046.             office products,  including word  processors and  desktop publishing  systems.
  5047.             Interchange of ODA  documents may be  by means of  data communications or  the
  5048.             exchange of storage media.  ODA documents may be in processable form (to allow
  5049.             further processing such as editing or reformatting) or in final form (to allow
  5050.             presentation as intended by the originator) or in both forms.  The key concept
  5051.             in the document architecture is that of structure -- the division and repeated
  5052.             subdivision  of  the content  of a  document  into increasingly  smaller parts
  5053.             called  objects.   Two  structures  are  defined by  ODA:  these  are  logical
  5054.             structure (contents  are divided based  on meaning, e.g.,  chapters, sections,
  5055.             paragraphs) and layout  structure (contents are  divided based on form,  e.g.,
  5056.             pages, blocks).
  5057.  
  5058.             Requirement
  5059.  
  5060.             A Document  Application Profile (DAP)  specifies the  constraints on  document
  5061.             structure and  content according to the rules of  the ODA standard.  Different
  5062.             DAPs  can  be  created  that apply  to  different  classes  of  document.   As
  5063.             extensions to ODA  are made, they will be incorporated into the DAPs specified
  5064.             in the Workshop Agreements.
  5065.  
  5066.             Status
  5067.  
  5068.                 A.  Standards -  ODA is an international  standard; however, several areas
  5069.             within ODA are currently being studied, enhanced and/or extended.  The primary
  5070.             emphasis  on   extensions  includes   new  content   architectures  (such   as
  5071.             spreadsheets and  audio) and new features  such as variant  of styles, complex
  5072.             tables,  alternative  representation,  computed  data  in  documents,  and  an
  5073.             interface to EDI.  Several addenda are planned to cover these extensions.
  5074.  
  5075.                 B.  Implementors' Agreements - The ODA SIG will examine extensions as they
  5076.             are  developed to determine whether  or not to  incorporate such extensions in
  5077.             DAPs.
  5078.  
  5079.             Plan
  5080.  
  5081.             The plan  is to  contribute  to the  work on  extensions  to ODA  through  the
  5082.             Workshop by informing standards groups of deficiencies and inadequacies of the
  5083.             standard  and to  incorporate developed extensions  into applicable  DAPs when
  5084.             these extensions are  mature.  GOSIP will reference applicable  DAPs which the
  5085.             National Computer Systems Laboratory (NCSL) plans  to issue for Federal agency
  5086.             use.
  5087.  
  5088.                                                   73
  5089.  
  5090.  
  5091.  
  5092.  
  5093.  
  5094.  
  5095.  
  5096.  
  5097.             4.2  GRAPHICS
  5098.  
  5099.             The  graphics requirements  for GOSIP include  the Computer  Graphics Metafile
  5100.             (CGM).    The  purpose of  CGM  is  to  facilitate  the  transfer  of  picture
  5101.             description   information  between   different  graphical   software  systems,
  5102.             different  graphical  devices and  different computer  graphics installations.
  5103.             CGM  specifies  a  file  format  suitable  for the  description,  storage  and
  5104.             communication  of  picture  description  information  in a  device-independent
  5105.             manner.
  5106.  
  5107.             Requirement
  5108.  
  5109.             FIPS PUB  128 announces  the adoption of  the American  National Standard  for
  5110.             Computer  Graphics  Metafile,  ANSI  X3.122-1986,  as  a  Federal  Information
  5111.             Processing Standard (FIPS).   This  standard is intended  for use in  computer
  5112.             graphics applications  that are either  developed or  acquired for  government
  5113.             use.    When  computer  graphics  metafile  systems for  GOSIP  are  developed
  5114.             internally,  acquired  as  part of  an  ADP  system  procurement, acquired  by
  5115.             separate procurement, used under an ADP  leasing arrangement, or specified for
  5116.             use in contracts for programming services, they shall conform to FIPS PUB 128.
  5117.  
  5118.             Status
  5119.  
  5120.                 A.  Standards  - Computer  Graphics Metafile  (CGM) ANSI  X3.122-1985, ISO
  5121.             8632/1-4-1987, FIPS 
  5122.             128-1987.
  5123.  
  5124.                 B.    Application  Profiles   -  MIL-D-28003  "Digital  Representation  of
  5125.             Communication of Illustration Data: CGM Application Profile" 30 December 1988.
  5126.  
  5127.             Plan
  5128.  
  5129.             An Application Profile (AP) defines additional requirements beyond ANSI CGM to
  5130.             ensure  interoperability   of  implementations   for  specific   applications.
  5131.             Currently, two  major application profiles exist for CGM;  the TOP AP, and the
  5132.             CALS AP (MIL-D-28003).   As these APs and other  APs which are applicable  for
  5133.             Federal  agency use are promulgated, they will  be incorporated into FIPS 128.
  5134.             GOSIP will  reference applicable  APs for CGM  which NCSL  plans to  issue for
  5135.             Federal agency use.
  5136.  
  5137.             4.3  STANDARD GENERALIZED MARKUP LANGUAGE (SGML) APPLICATION PROFILE
  5138.  
  5139.             Description
  5140.  
  5141.             The Standard Generalized  Markup Language (SGML) standardizes  the application
  5142.             of the generic coding and generalized markup concepts.  It provides a coherent
  5143.             and unambiguous  syntax for  describing whatever  a user  chooses to  identify
  5144.             within  a  document.   It is  a  metalanguage for  describing the  logical and
  5145.             content structure of a document in a machine processable syntax.  The Standard
  5146.             Generalized  Markup Language can  be used for documents  that are processed by
  5147.             any  text  processing or  word  processing system.    It will  be particularly
  5148.  
  5149.                                                   74
  5150.  
  5151.  
  5152.  
  5153.  
  5154.  
  5155.  
  5156.  
  5157.             applicable to:
  5158.  
  5159.                 o documents  that  are  interchanged  among  systems with  differing  text
  5160.             processing languages
  5161.  
  5162.                 o documents  that are  processed  in  more than  one  way,  even when  the
  5163.                   procedures use the same text processing language.
  5164.  
  5165.             Requirement
  5166.  
  5167.             FIPS  PUB   152  announces  the   adoption  of  the   International  Standards
  5168.             Organization Standard Generalized Markup Language (SGML), ISO  8879-1986, as a
  5169.             Federal Information Processing Standard (FIPS).  This standard is intended for
  5170.             use in documents  that are processed by  any text processing systems  that are
  5171.             either developed  or acquired for government  use.  When  SGML text processing
  5172.             systems for GOSIP are developed internally, acquired  as part of an ADP system
  5173.             procurement,  acquired by  separate  procurement, used  under  an ADP  leasing
  5174.             arrangement, or specified for use in  contracts for programming services, they
  5175.             shall conform to FIPS PUB 152.
  5176.  
  5177.  
  5178.             Status
  5179.  
  5180.                   A.   Standards  -  Information Processing  - Text  and office  systems -
  5181.             Standard Generalized Markup Language (SGML), ISO 8879-1986 (E),FIPS 152-1988.
  5182.  
  5183.                   B.    Application  Profiles  -  MIL-M-28001A, "Markup  Requirements  and
  5184.             Generic  Style Specification  for Electronic  Printed Output  and  Exchange of
  5185.             Text," December 1989.
  5186.  
  5187.             MIL-M-28001A,  "Markup  Requirements  and  Generic  Style  Specifications  for
  5188.             Electronic Printed  Output and Exchange of Text," established the requirements
  5189.             for the digital  data form of  page oriented technical military  publications.
  5190.             Data  prepared  in  conformance  to  these requirements  will  facilitate  the
  5191.             automated  storage,  retrieval,  interchange,  and   processing  of  technical
  5192.             documents from heterogeneous data sources.  MIL-M-28001A requirements include:
  5193.  
  5194.                 o procedures and  symbology for markup  of unformatted text  in accordance
  5195.                   with  this  specific  application  of  the Standard  Generalized  Markup
  5196.                   Language;
  5197.  
  5198.                 o SGML  compatible  codes  that  will  support  encoding  of  a  technical
  5199.                   publication  to  specific  format requirements  applicable  to technical
  5200.                   manuals;
  5201.  
  5202.                 o output processing requirements that will format a conforming SGML source
  5203.                   file to the style and format  requirements of the appropriate Formatting
  5204.                   Output Specification Instance (FOSI).
  5205.  
  5206.             Plan
  5207.  
  5208.             An Application Profile (AP)  defines additional requirements beyond  FIPS SGML
  5209.  
  5210.                                                   75
  5211.  
  5212.  
  5213.  
  5214.  
  5215.  
  5216.  
  5217.  
  5218.             to  ensure interoperability of implementation.   MIL-M-28001 is an Application
  5219.             Profile for technical military publications.   The plan is to develop an  SGML
  5220.             Document Application Profile (SDAP) by extending MIL-M-28001 to be more useful
  5221.             for  generic documents and to incorporate the  SDAP into FIPS 152.  GOSIP will
  5222.             reference applicable SDAPs which NCSL plans to issue for Federal agency use.
  5223.  
  5224.  
  5225.  
  5226.  
  5227.  
  5228.  
  5229.  
  5230.  
  5231.  
  5232.  
  5233.  
  5234.  
  5235.  
  5236.  
  5237.  
  5238.  
  5239.  
  5240.  
  5241.  
  5242.  
  5243.  
  5244.  
  5245.  
  5246.  
  5247.  
  5248.  
  5249.  
  5250.  
  5251.  
  5252.  
  5253.  
  5254.  
  5255.  
  5256.  
  5257.  
  5258.  
  5259.  
  5260.  
  5261.  
  5262.  
  5263.  
  5264.  
  5265.  
  5266.  
  5267.  
  5268.  
  5269.  
  5270.  
  5271.                                                   76
  5272.  
  5273.  
  5274.  
  5275.  
  5276.  
  5277.  
  5278.  
  5279.                                   APPENDIX 5.  LOWER LAYER PROTOCOLS
  5280.  
  5281.  
  5282.             5.1  IS-IS DYNAMIC ROUTING PROTOCOLS
  5283.  
  5284.             Within  OSI networks,  systems of  routers (intermediate  systems) enable  the
  5285.             effective and efficient interconnection  of a diverse set of  subnetwork types
  5286.             (e.g., CSMA/CD,  token ring, token bus, and  X.25) into internetworks.  Within
  5287.             such an  internetwork, messages are  sent like postal  letters from router  to
  5288.             router.  At each router a message is examined and the next router is selected.
  5289.             The effect  of such a  scheme is that  each message may  follow an independent
  5290.             route.  As  conditions within the internetwork  change (e.g., link, host,  and
  5291.             router failures and activations), the possibility exists for messages to reach
  5292.             their destination despite  failure of  network elements.   Such potential  can
  5293.             only be achieved if the system of routers exchanges information concerning the
  5294.             state  of  routes.   Protocols for  exchanging information  concerning varying
  5295.             route  conditions  are  known  as  dynamic  routing  protocols.    Within  OSI
  5296.             standards,  dynamic  routing  protocols  are   named  intermediate  system  to
  5297.             intermediate system (IS-IS) protocols.
  5298.  
  5299.             Requirement
  5300.  
  5301.             Dynamic routing is required within GOSIP to support the needs of several large
  5302.             government  internetworks.   Two  kinds of  routing  support are  required: 1)
  5303.             dynamic  routing  within  an administrative  domain,  and  2) dynamic  routing
  5304.             between administrative domains.  Routing requirements within an administrative
  5305.             domain  are  well understood,  and  two  generally  acceptable schemes  exist.
  5306.             Routing  requirements  between administrative  domains  are not  widely agreed
  5307.             upon, although ECMA has produced a technical report.
  5308.  
  5309.             Status
  5310.  
  5311.             An intra-domain dynamic routing protocol was submitted to ISO from ASC X3S53.3
  5312.             in January 1988.  The submission is based on DEC's Phase V link state routing.
  5313.             It was discussed at the November  ISO SC6/WG2 meeting and was registered as  a
  5314.             DP in January 1990.
  5315.  
  5316.             ECMA developed  an inter-domain  technical report  (TR50), based  on an  NIST-
  5317.             developed model.  It was submitted by ECMA as a liaison to ISO WG2 in May 1989
  5318.             as the proposed basis for an ISO inter-domain standard.
  5319.  
  5320.             Plan
  5321.  
  5322.             The NIST will support the progression  of the DEC submission toward an  ISO IS
  5323.             through work in  standards committees and  laboratories.   The NIST will  also
  5324.             prepare  for establishing implementor agreements  as the document reaches DIS.
  5325.             The NIST  will continue  to support  development of  the inter-domain  routing
  5326.             protocol within ECMA, ANSI, and ISO.
  5327.  
  5328.             The  GOSIP  will  adopt intra-domain  dynamic  routing  protocols  as soon  as
  5329.             implementor agreements  are  in place.    The projected  date  is 1991.    The
  5330.             adoption of an inter-domain routing protocol for GOSIP should occur one to two
  5331.  
  5332.                                                   77
  5333.  
  5334.  
  5335.  
  5336.  
  5337.  
  5338.  
  5339.  
  5340.             years following adoption of an intra-domain protocol.
  5341.  
  5342.             5.2  FIBER DISTRIBUTED DATA INTERFACE (FDDI)
  5343.  
  5344.             FDDI is a 100 Mbit/s token ring network utilizing multimode fiber optic media.
  5345.             Three  standards,  Physical Medium  Dependent  (PMD), Physical  Layer Protocol
  5346.             (PHY),  and Medium Access  Control (MAC)  specify the  Physical and  Data Link
  5347.             layers  of  the  Open  Systems  Interconnection  Reference Model.    A  fourth
  5348.             standard, Station Management  (SMT) interfaces  to the first  three layers  to
  5349.             control   initialization  and   configuration  of   the  ring,   as   well  as
  5350.             reconfiguration around faults, and will  provide management services to higher
  5351.             layer management protocols.
  5352.  
  5353.  
  5354.  
  5355.             Requirement
  5356.  
  5357.             MAC, PHY and PMD have a few options which require  selection (e.g., 48 bit vs.
  5358.             16 bit  addressing) and  a  few timers  and parameters  which require  further
  5359.             definition (particularly of  their default values) to  ensure interoperability
  5360.             in  an OSI  environment.   One  class of  service (Restricted  Token  Mode) is
  5361.             inappropriate in an OSI environment.
  5362.  
  5363.             SMT  is  more complex,  and  will  probably offer  many  options, particularly
  5364.             regarding network policies, which will require some selection.  In many cases,
  5365.             this will simply mean selecting the default option or policy.
  5366.  
  5367.             Status
  5368.  
  5369.                 A.   Standards - The MAC (X3.139-1987) PHY (X3.148-1988)  and PMD (X3.166-
  5370.             1989) standards  are approved.   SMT is still  under development and  probably
  5371.             will be forwarded  in June 1990 and  approved in 1991.   Products implementing
  5372.             FDDI are now widely available.
  5373.  
  5374.                 B.     Implementors'  Agreements  -  NIST  has  drafted  an  implementors'
  5375.             agreement covering  MAC, PHY  and PMD.   This  was accepted  into the  ongoing
  5376.             agreements by the Lower Level SIG and should be incorporated in Version 3.0 of
  5377.             GOSIP.  Although products are now starting to appear, SMT is not approved, but
  5378.             is "stable", so work could begin on an implementors' agreement by mid-1990.
  5379.              
  5380.             Plan
  5381.  
  5382.             NIST will draft a proposed implementors'  agreement covering SMT after SMT  is
  5383.             forwarded to approval,  which will probably occur in June.  The ANSI standard,
  5384.             moreover, will not be completely stable until some time in 1990 or 199l, since
  5385.             the public review  usually results  in changes.   That means  that closure  on
  5386.             implementors'  agreements cannot be  reached before some  time in 1991  at the
  5387.             earliest.   This is  not  ideal, because  there  will be  significant  product
  5388.             shipments in 1990.  
  5389.  
  5390.             Since SMT  is largely  software, vendors  expect to  update equipment  already
  5391.             shipped before SMT  is finalized, by  distributing new software (often  on ROM
  5392.  
  5393.                                                   78
  5394.  
  5395.  
  5396.  
  5397.  
  5398.  
  5399.  
  5400.  
  5401.             chips).
  5402.  
  5403.             5.3  TRANSPORT PROTOCOL CLASS 2
  5404.  
  5405.             The transport protocol, class 2, for  use over the connection-oriented network
  5406.             service (CONS)  is accepted  by several OSI  profiles (e.g.,  UK GOSIP).   The
  5407.             transport protocol, class 2, is also used with CONS in several U.S. Government
  5408.             applications, where communication is confined to a single logical subnetwork.
  5409.  
  5410.             Requirement
  5411.  
  5412.             The transport protocol, class 2, is desired in GOSIP as an  optional transport
  5413.             protocol  for use  with  CONS, where  communication  is confined  to a  single
  5414.             logical  subnetwork.   The  transport protocol,  class  4, operating  over the
  5415.             connectionless network  service (CLNS),  will remain  the sole  mandatory data
  5416.             transport service for purposes of interoperability among U. S. GOSIP-compliant
  5417.             computer systems.  The specification of the transport protocol, class 2, as an
  5418.             option in GOSIP, is intended to  enable interoperability among U.S. Government
  5419.             computer systems, when using class 2 transport over CONS.  Such specifications
  5420.             would be intended to prevent the spread of non-interoperable class 2 transport
  5421.             implementations  within the  U. S.  Government.   The  ability  to choose  the
  5422.             correct transport protocol  class for a  given instance of communication  will
  5423.             require a prior knowledge  on the part of the transport  connection initiator,
  5424.             until directory services are included in GOSIP.
  5425.  
  5426.             Status
  5427.  
  5428.             Although a few  U.S. vendors provide implementations of the  class 2 transport
  5429.             protocol,  the  overwhelming  majority offer  class  4  transport  only.   The
  5430.             Workshop Agreements endorse class 4 transport for use over 
  5431.  
  5432.             CLNS and CONS, and class 0 transport  for use over CONS when direct access  to
  5433.             public messaging systems is required.
  5434.  
  5435.             Plan
  5436.  
  5437.             Interested  government agencies brought the  requirement for class 2 transport
  5438.             implementation  agreements to  the attention  of the  Lower Layer  SIG  of the
  5439.             NIST/OSI Implementors' Workshop.   Workshop  Agreements are now  in place,  so
  5440.             consideration  canbe  given to  inclusion  of  an optional  class  2 transport
  5441.             capability into GOSIP, Version 3.0.  
  5442.  
  5443.             5.4  INTEGRATED SERVICES DIGITAL NETWORK
  5444.  
  5445.             Integrated  Services Digital  Networks  (ISDN),  supporting integrated  voice,
  5446.             data,  image, and  video  are expected  to  be  deployed on  a  wide scale  in
  5447.             ubiquitous public offerings and in private  network offerings, as services and
  5448.             as components  from which private ISDN  networks can be  constructed.  Initial
  5449.             offerings  will  be  a switched  64  kbps  service delivered  to  a customer's
  5450.             terminal  at a  basic rate  (16 Kbps signaling  channel and  two 64  KBPS data
  5451.             channels) or a  primary rate (24 64  Kbps channels, one used  for signalling).
  5452.             Later offerings, now in the development  phases, will offer higher capacities,
  5453.  
  5454.                                                   79
  5455.  
  5456.  
  5457.  
  5458.  
  5459.  
  5460.  
  5461.  
  5462.             estimated at 150 Mbps to 622 Mbps.
  5463.  
  5464.             Requirement
  5465.  
  5466.             One use for ISDN is to provide a bearer service for OSI data protocols;  thus,
  5467.             ISDN is included in  GOSIP as a lower layer service.   Other ISDN applications
  5468.             include integrated voice,  image, data, and  video, and, therefore,  non-GOSIP
  5469.             ISDN applications can be expected.  NIST plans to issue a variety of FIPS that
  5470.             enable the government to exploit the full technical capabilities of ISDN.  The
  5471.             initial focus aims at switched 64 Kbps  service for voice, voice/data, and, in
  5472.             GOSIP,  OSI data.    Both the  basic  and primary  rates  are needed.    Later
  5473.             broadband ISDN (B-ISDN) is needed.   The initial fundamental requirements are:
  5474.             1) specifications enabling multi-vendor  interconnection compatibility between
  5475.             terminal  equipment  and switching  equipment  and 2)  specifications enabling
  5476.             multi-vendor interconnection compatibility between switching equipment.  
  5477.  
  5478.             Status
  5479.  
  5480.             The North American ISDN Users Forum  (NIU-FORUM), comprising a user's workshop
  5481.             (IUW) and  an implementor's  workshop (IIW),  is addressing  issues of  multi-
  5482.             vendor  terminal equipment-to-switch  and switch-to-switch  interoperation and
  5483.             ISDN application  profiles.   Some implementation  agreements and  application
  5484.             profiles are expected by the end of 1990.
  5485.  
  5486.             Plan
  5487.  
  5488.             The GOSIP FIPS will reference appropriate IIW agreements and ISDN FIPS as they
  5489.             become available.  NIST plans to issue  ISDN FIPS for integrated voice, image,
  5490.             data,  and video and  non-OSI data, as appropriate  agreements are achieved in
  5491.             the IIW and IUW.   The primary requirement for  ISDN in GOSIP is as  a network
  5492.             bearer service accessible via terminal equipment and switching equipment  that
  5493.             can be connected readily, regardless of  the specific vendor.  The GOSIP  FIPS
  5494.             will evolve to account for availability of B-ISDN and the Synchronized Optical
  5495.             Network (SONET).
  5496.  
  5497.  
  5498.  
  5499.  
  5500.  
  5501.  
  5502.  
  5503.  
  5504.  
  5505.  
  5506.  
  5507.  
  5508.  
  5509.  
  5510.  
  5511.  
  5512.  
  5513.  
  5514.  
  5515.                                                   80
  5516.  
  5517.  
  5518.  
  5519.  
  5520.  
  5521.  
  5522.  
  5523.                                          APPENDIX 6.  ACRONYMS
  5524.  
  5525.  
  5526.             ACSE        Association Control Service Element
  5527.             AE          Application Entity
  5528.             AFI         Authority and Format Identifier
  5529.             ANSI        American National Standards Institute
  5530.             AP          Application Profile
  5531.             ASCII       American Standard Code for Information Interchange
  5532.             ASN         Abstract Syntax Notation
  5533.             BRI         Basic Rate Interface
  5534.             CCITT       Consultative Committee for International Telegraph & Telephone
  5535.             CGM   Computer Graphics Metafile
  5536.             CLNP        Connectionless Network Protocol
  5537.             CLNS        Connectionless Network Service
  5538.             CLTP        Connectionless Transport Protocol
  5539.             CLTS        Connectionless Transport Service
  5540.             CMIP        Common Management Information Protocol
  5541.             CMIS        Common Management Information Services
  5542.             CONS        Connection-Oriented Network Service
  5543.             COTS        Connection-Oriented Transport Service
  5544.             CSMA/CD     Carrier Sense, Multiple Access with Collision Detection
  5545.             DAP         Document Application Profile
  5546.             DIS         Draft International Standard
  5547.             DOD   Department of Defense
  5548.             DOE         Department of Energy
  5549.             DP          Draft Proposal
  5550.             DSP         Domain Specific Part
  5551.             DTR         Draft Technical Report
  5552.             ECMA        European Computer Manufacturers Association
  5553.             EIA         Electronic Industries Association
  5554.             ES-IS       End System-Intermediate System
  5555.             FADU        File Access Data Unit
  5556.             FAR         Federal Acquisition Regulation
  5557.             FDDI        Fiber Distributed Data Interface
  5558.             FIB         Forwarding Information Base
  5559.             FIPS              Federal Information Processing Standard
  5560.             FIRMR       Federal Information Resources Management Regulation
  5561.             FTAM        File Transfer, Access, and Management 
  5562.             GENSER      General Service
  5563.             GOSIP       Government Open Systems Interconnection Profile
  5564.             GSA         General Services Administration
  5565.             HDLC        High Level Data Link Control
  5566.             ICD         International Code Designator
  5567.             IDI         Initial Domain Identifier
  5568.             IDP         Initial Domain Part
  5569.             IEC         International Electrotechnical Commission
  5570.             IEEE        Institute of Electrical and Electronic Engineers
  5571.             IRV         International Reference Version 
  5572.             IS          International Standard
  5573.             IS          Intermediate System
  5574.             IS-IS             Intermediate System-Intermediate System
  5575.  
  5576.                                                   81
  5577.  
  5578.  
  5579.  
  5580.  
  5581.  
  5582.  
  5583.  
  5584.             ISDN        Integrated Services Digital Network
  5585.             ISO         International Organization for Standardization
  5586.             JTC         Joint Technical Committee
  5587.             LAN         Local Area Network
  5588.             LAPB        Link Access Procedure B
  5589.             LAPD        Link Access Procedure D 
  5590.             MAC   Medium Access Control
  5591.             MAP         Manufacturing Automation Protocol
  5592.             MHS   Message Handling Systems
  5593.             MMS   Manufacturing Message Specification
  5594.             NCS         National Communications System
  5595.             NIST        National Institute of Standards and Technology
  5596.             NMSIG       Network Management Special Interest Group
  5597.             NPDU        Network Protocol Data Unit
  5598.             NPAI        Network Protocol Access Information
  5599.             NSA         National Security Agency
  5600.             NSAP        Network Service Access Point
  5601.             ODA         Office Document Architecture
  5602.             OSIO        Open Systems Interconnection
  5603.             PCI         Protocol Control Information
  5604.             PDN         Public Data Network
  5605.             PDU         Protocol Data Unit
  5606.             PHY         Physical Layer Protocol
  5607.             PLP         Packet Level Protocol
  5608.             PMD   Physical Medium Dependent
  5609.             PRI         Primary Rate Interface
  5610.             PSAP        Presentation Service Access Point
  5611.             RDA         Remote Database Access
  5612.             RFP         Request For Proposal
  5613.             RIB         Routing Information Base
  5614.             SAP         Service Access Point
  5615.             SC          Steering Committee
  5616.             SCI         Special Compartmented Information
  5617.             SDNS        Secure Data Network Service
  5618.             SGML        Standard Generalized Markup Language
  5619.             SIG         Special Interest Group
  5620.             SILS              Standard for Interoperable LAN Security
  5621.             SIOP-ESI    Single Integrated Operational Plan-Extremely Sensitive Info.
  5622.             SMT         Station Management
  5623.             SNPA        Subnetwork Point of Attachment
  5624.             SQL         Structured Query Language
  5625.             SSAP        Session Service Access Point
  5626.             SVC         Switched Virtual Circuit
  5627.             TC          Technical Committee
  5628.             TOP         Technical and Office Protocols
  5629.             TP          Transaction Processing
  5630.             TSAP        Transport Service Access Point
  5631.             TTY         Teletype
  5632.             VT          Virtual Terminal
  5633.             WAN   Wide Area Network
  5634.             WG          Working Group
  5635.             WYSIWYG     What You See Is What You Get
  5636.  
  5637.                                                   82
  5638.  
  5639.  
  5640.  
  5641.  
  5642.  
  5643.  
  5644.  
  5645.  
  5646.  
  5647.  
  5648.  
  5649.  
  5650.  
  5651.  
  5652.  
  5653.  
  5654.  
  5655.  
  5656.  
  5657.  
  5658.  
  5659.  
  5660.  
  5661.  
  5662.  
  5663.  
  5664.  
  5665.  
  5666.  
  5667.  
  5668.  
  5669.  
  5670.  
  5671.  
  5672.  
  5673.  
  5674.  
  5675.  
  5676.  
  5677.  
  5678.  
  5679.  
  5680.  
  5681.  
  5682.  
  5683.  
  5684.  
  5685.  
  5686.  
  5687.  
  5688.  
  5689.  
  5690.  
  5691.  
  5692.  
  5693.  
  5694.  
  5695.  
  5696.  
  5697.  
  5698.                                                   83
  5699.